目前云正在迅速崛起，人们开始将所有内容部署到云端，包括CMS系统，但到目前为止，我还没有看到成功将流行的CMS系统部署到云中的负载平衡群集的人。一些性能障碍似乎阻止了标准的开源CMS系统像这样部署到云端。
云：云，更好的负载平衡群集，至少有一个前端服务器，一个网络连接（！）数据库服务器和一个云存储服务器。这非常适合Amazon Beanstalk和Google Appengine。 （这在具有相同“CPU”的MySQL的单台计算机或Linux服务器上明确排除了CMS。）
要在此类负载平衡群集中部署标准CMS，需要具备以下特征的云就绪CMS：
目前我知道python / django和Wordpress的中间件模块或插件可以连接到云存储而不是文件系统，但可能还有其他支持云的CMS实现（Java，PHP，？）和系统。
我自己未能将django-CMS部署到云端，最终由于远程数据库的查询延迟。所以这是我的问题：
您是否部署了在呈现网页和后端管理员方面仍然表现良好的开源CMS？请为未缓存的网页发布平均页面呈现访问统计信息（以微秒为单位）。
重要提示：请描述您的配置，遇到的问题，必须在CMS中优化哪些模块才能使其正常工作，不要发布简单的“这个工作”，贡献您的经验和知识。< /强>
这样的CMS可能每页只需要少于10个查询，如果更多，查询必须并行进行，并处理文件系统访问时间100ms，统计和查询延迟为40ms。
相关：
答案 0 :(得分：1)
答案 1 :(得分：0)
我们已经设法在GoogleAppEngine上部署python django-CMS（www.django-cms.org），其中CloudSQL为DB，CloudStore为Filesystem。通过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，基本上消除了所有存储/“文件”系统访问。一旦修复了这个问题，简易缩略图就会替换（按设计）文件系统访问，并向DB提出查询，以便在缩略图的源图像发生变化时检查每个请求。
网页设计师的一件事：如果她在模板中使用了image.width语句，则会强制对“文件系统”进行难看的慢速读取，因为图像宽度不会被缓存。
进一步调查得出的结论是，数据库访问成本非常高，每次往返大约需要40毫秒。
到目前为止，部署不成功主要是由于云中的数据库访问时间导致在缓存之前渲染页面的时间延迟了4-5秒。
答案 2 :(得分：0)
我在Appengine上发现了Wordpress的出色性能测试。 Google似乎花了一些时间来优化此系统，以实现负载均衡的群集和远程数据库部署：
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
从报告中得出结论，系统比传统托管慢，但扩展得更好。