最快的云/集群部署开源内容管理系统答案

【问题标题】：Fastest Open Source Content Management System for Cloud/Cluster deployment最快的云/集群部署开源内容管理系统
【发布时间】：2014-01-15 21:47:18
【问题描述】：

目前云正在疯狂地涌现，人们开始将一切都部署到云中，包括 CMS 系统，但到目前为止，我还没有看到有人成功地将流行的 CMS 系统部署到云中的负载平衡集群。一些性能障碍似乎阻止了标准的开源 CMS 系统像这样部署到云中。

CLOUD：云，负载平衡更好的集群，至少有一个前端服务器，一个网络连接（！）数据库服务器和一个云存储服务器。这非常适合 Amazon Beanstalk 和 Google Appengine。（这特别排除了单个计算机上的 CMS 或 Linux 服务器上的 MySQL 在同一个“CPU”上。）

要在这样的负载平衡集群中部署标准 CMS，需要具有以下特性的云就绪 CMS：

CMS 必须处理查询延迟，才能在不到一秒的时间内响应并呈现页面以进行缓存（或使用预缓存策略）
文件系统可能必须连接到远程存储（Amazon S3、Google 云存储等）

目前我知道 python/django 和 Wordpress 具有可以连接到云存储而不是文件系统的中间件模块或插件，但可能还有其他云就绪 CMS 实现（Java、PHP、？）和系统。

我自己未能将 django-CMS 部署到云端，最后是由于远程数据库的查询延迟。所以这是我的问题：

您是否部署了在呈现页面和后端管理方面仍然表现良好的开源 CMS？请以微秒为单位发布未缓存页面的平均页面呈现访问统计信息。

重要提示：请描述您的配置，您遇到的问题，在 CMS 中必须优化哪些模块才能使其工作，不要发布简单的“这个工作”，贡献您的经验和知识。

这样的 CMS 可能每页必须进行少于 10 次查询，如果更多，则必须并行进行查询，并处理 100 毫秒的文件系统访问时间和 40 毫秒的查询延迟。

相关：

Slow MySQL Remote Connection

【问题讨论】：

我有点困惑...CMS 系统主要依赖于数据库...如果您已经拥有一个现场数据库，您使用云存储做什么？
云存储存储二进制文件、图像、视频 (en.wikipedia.org/wiki/Cloud_storage) CMS 通常存储在数据库之外的 Linux 文件系统上的任何内容。云存储通常可以配置为将内容作为静态网站提供，无需 CMS 干预。
我认为 AppEngine（因为你在这里问）对于 CMS 工作负载没有竞争力，因为 Datastore 是为大量小记录而设计的，而 Content 通常是少量较大的文档。存储文档的最佳性价比选项是文件系统，而 AppEngine 和其他云平台必须拒绝 Web 应用程序文件系统访问。只有 AppEngine 中的 Blobstore 可以存储文件，但这是一个没有文件夹、权限等的键值结构。总之，AppEngine等云平台的功能集不够适合CMS使用。
Martin，您必须更新有关 cloudstore 及其应用引擎集成的知识。 Google CloudStore 是 Appengine 的一种文件系统，也是一个静态网站。 Appengine 也可以使用 CloudSQL 而不是 Datastore。这就是我们安装 django-CMS 的方式（参见：stackoverflow.com/questions/21137634/…）它只是表现不佳，因为渲染一个页面需要 40 个查询需要 2 秒。这就像在拥有 10 年历史的硬件上运行当前的 CMS，具有巨大的硬盘。
你无法超越物理定律，而遥远的数据库是“慢”的秘诀。您也不能在这里随意重新定义“云”，并且指定文件系统位于 Amazon S3 或 Google Cloud Storage 中是特别不合理的，因为这些服务之间存在显着的阻抗不匹配......文件系统是。这些是错误的工具，因此，当您使用它们代替更合适的工具时，它们就不能很好地工作。围绕“有人知道...”的购物清单问题不在 Stack Overflow 的主题范围内。

标签： google-app-engine azure amazon-web-services content-management-system

【解决方案1】：

你试过 Umbraco 吗？

它依赖于数据库，但它保留了缓存层，因此您不必对每个请求进行选择。

http://umbraco.com/azure

它也适用于 azure！

【讨论】：

这个符合维基百科的要求：“在负载较高的情况下提供内容的 Umbraco 站点也可以部署在负载平衡的集群上”（来源 en.wikipedia.org/wiki/Umbraco）

【解决方案2】：

我在 Appengine 上找到了一个出色的 Wordpress 性能测试。谷歌似乎花了一些时间来优化这个系统以实现负载平衡集群和远程数据库部署：

http://www.syseleven.de/blog/4118/google-app-engine-php/

报告中的缩放测试。

parallel
hits    GAE  1&1  Sys11
1       1,5  2,6    8,5
10      9,8  8,5   69,4
100    14,9   -   146,1

报告得出的结论是，系统比传统托管慢，但可扩展性更好。

http://developers.google.com/appengine/articles/wordpress

【讨论】：

【解决方案3】：

我们已经成功地在 GoogleAppEngine 上部署了 python django-CMS (www.django-cms.org)，其中 CloudSQL 作为数据库，CloudStore 作为文件系统。 Cloud store 是通过 Christos Kopanos http://github.com/locandy/django-google-cloud-storage 分叉和修复一个 django.storage 模块来附加的

之后，第二组问题出现了，因为我们发现单页访问的访问时间长达 17 秒。我们对此进行了调查，发现easy-thumbnails 1.4 访问了mod_time 请求的正常文件系统，同时将结果写入存储（在每个请求上呈现所有缩略图）。我们切换到已经修复的开发版本。

然后，我们与 SmileyChris 合作，通过跟踪问题并将问题发布到 http://github.com/SmileyChris/easy-thumbnails

，修复了对每个图像的每个请求的 mod_times（统计文件）的不必要访问

这将 CMS 上每个公共页面的访问时间从 12-17 秒减少到 4-6 秒，基本上消除了所有存储/“文件”系统访问。一旦解决了这个问题，简单的缩略图将替换（按设计）文件系统访问，并使用对数据库的查询来检查每个请求，如果缩略图的源图像发生了变化。

对于网页设计师的一件事：如果她在模板中使用 image.width 语句，这会强制“文件系统”读取速度很慢，因为图像宽度没有被缓存。

进一步调查得出结论，数据库访问的成本也非常高，每次往返大约需要 40 毫秒。

到目前为止，部署不成功，主要是由于云中的数据库访问时间导致在缓存页面之前渲染页面延迟 4-5 秒。

【讨论】：