大容量网站的可扩展的WordPress主机？

Dedicated, Dedicated, Dedicated, Dedicated </steveballmer> 

好的，这是我的系统。 如果我真的认真考虑一个这样高的交通网站，真的，500khits /小时是一个很大的。

我真的真的考虑build立我自己的networking和群集来承载它。 我可能会用4节点的系统来卸载。 2个前端运行Varnish Cache， 2个后端运行Apache和MySQL作为后端。 在后端之间进行循环复制，并为会话同步运行memcached。

或者你可以把Varnish和Apache放在服务器上，让数据库服务器只做数据库。 想想看，这可能是一个更好的select。

我对虚拟化服务器上​​的高stream量站点感到担忧。 主要是因为IO的性能，也是因为它可能对相同服务器上的其他虚拟机的性能非常不利，但这确实意味着其他人的stream量可能会干扰您的网站。

可湿性粉剂并没有你想象的那么糟糕。 你将不得不做许多优化，媒体的cookieless域，你所提到的所有事情将有所帮助。 你需要2层caching，或者3/4层。 CDN，ReverseProxycaching，也可能受益于使用memcache的查询caching，以及使用APC进行操作码caching。

有很多可以做的小优化，这将大大提高性能，他们都值得调查。

VarnishCache使得一个很好的反向代理caching，但也是一个非常好的负载平衡器，相信我，你会想要多个后端服务器。 如果你的网站很重要，正常运行时间对你来说意味着什么（这是否使你赚钱），那么你肯定会想要多个服务器。

想想看，如果你提供了大量的媒体资源，图像等，我肯定会考虑另外几台服务器，可能运行nginx而不是apache，为media.yourdomain.com服务，或者完全不同的cookie域，就像在stackexchange站点上使用的sstatic.net域一样。

这里有一个如何实现的例子，但是你必须把RFC1918范围之外的IP地址改为可公开路由的IP地址;）

任何人在抱怨多个Alogging之前，我都会把它扼杀在萌芽状态。 如果不进行第3层，并且使用BGP或GSLB来实现高可用性，那么使用循环DNS来进行非智能的负载平衡是一个不错的方法，而不是太昂贵，实际上相当便宜。 您可以使用像Dynect这样的服务来实现稍微智能的DNS，在向您的负载均衡器发送请求之前，它将执行一定级别的主机检查。

如果你select一个好的专用服务器主机，他们可能会做一些，或为你的所有上述。 考虑到您预计会有相当多的stream量，我可以很容易地说一个便宜的专用服务器（低于200-300美元/月）很可能是一个虚假的经济，并且无法支持您所拥有的stream量期待得到。

VPS.net是一个高度容错的完全可扩展的解决scheme。 价格低廉，function强大，灵活。 MediaTemple是另一个不错的提供商，因为您可以从function不太强大的虚拟机开始，然后基本上按一下button就可以扩展到自己的服务器。 您应该寻找一个可以快速水平（冗余/群集）和垂直（更多存储/ CPU / RAM）扩展的提供商。

我们使用Rackspace Cloud，它的尺寸非常适合我们的需求。 请勿将其与Cloud Sites混淆，而应将其与Cloud Server混淆。 基本上你build立你自己的群集，你可以扩展它，但是你想要的。

我运行一个WordPress的托pipe公司，但说实话，我没有遇到你谈论的stream量，所以我不想把我的帽子跑，我会很乐意帮助你从自己的经验中学习什么有用，什么没有用。

对于高容量的WordPress主机，我会去与WordPress的VIP

WordPress VIP Hosting运行在3个数据中心的1200台服务器上，负载平衡的WordPress.com骨干网上。

你得到什么：

• 您的网站在WordPress.com网格上运行（三个数据中心中的超过1,200台服务器）
• 无限的空间和带宽
• 全天候的IT支持
• 内容分发networking和每小时的备份
• 企业级Akismet垃圾邮件防护
• 针对您的网站主题的优化和安全反馈，为您提供更快，更安全的网站
• 整合WordPress.comfunction，如“今日博客”，“我的评论”，“标签冲浪者”和“Gravatars”
• 在我们的发布者博客上推广您的新博客
• 网站地图和新闻站点更好的search引擎和谷歌新闻曝光
• login到WordPress.com的用户将login到您的域名，使他们更容易评论您的博客

成本

每月大约$ 2,500。

我不能从任何个人经验中发言，但WP Engine是专门为这个问题而build立的。

Syed Karim 问道 ：“你在哪里/如何最终托pipe这个网站？”这是我的“从前面的笔记”：

我没有find任何“automagical”服务或解决scheme。 WordPress.com VIP主机，WP引擎，和其他一些看起来很有趣，但不适合这个法案。 所以我们直接托pipe在amazon web services（AWS）上。

我们使用了（几个大的）EC2服务器实例+基于Mercurial的Elastic Load Balancer + S3 / CloudFront卸载I / O +优化/缩小+caching+ CloudWatch Monitoring + SNS通知+ Python / bash自动化/脚本+复制。

TL; DR详细信息：

这个网站是一个1M +人的事件的闪电网站。 在事件发生前15天，它只有名义上的游客，但随后开始加速成为一个激烈的斜坡，在T-3天左右进行了激进的攀登。 无论是使用Google Analytics（分析）还是使用网站效果监视器，您都可以逐个小时观看负载。

我们使用EC2服务器，运行Ubuntu“Natty Narwhal”，MySQL 5.1和WordPress 3.x. 它们被弹性负载均衡器所支持。 我们必须将DNS转移到亚马逊的Route 53服务上，以使ELB能够正常工作（例如domain.tld而不是www.domain.tld）。

对于服务器，为了避免共享/复制/集群化MySQL和NFS / CFS文件池的复杂性和潜在故障模式，我们宁愿扩大规模。 我们可以并且确实可以扩展，但在“最终一致”和“所有节点使用自己的本地存储”方式。 对主服务器进行了网站更改，然后将文件和数据库更改复制到WP池的其余部分。 复制是由Mercurial和SCP的组合处理的（有更奇特的方法，这些都很简单，而且效果很好）。

在这种configuration下，最终一致<=〜3分钟。 也就是说，有些用户在更新后的几分钟内可能会看到较旧的内容。

负载下的WordPress需要CPU比内存快得多，所以我们最终在内存上进行了过度configuration。 但是我们需要CPU，价格/复杂性权衡是正确的，因为我们处于高峰运行的时间有限。

我们考虑了一个自动调节configuration，但是知道峰值负载的持续时间和可能的需求曲线，并且具有良好的性能指标和警报（从CloudWatch和SNS开始），我们select了手动调整 – 另一个成功的KISSselect。

最常见的缩放操作是激活下一个最大的实例，自动加载所需的软件，自动复制站点内容，并将其添加到ELB组。 从头开始，实例激活通常在3分钟内完成。 通过人工确认，服务器正常运行并将其添加到负载均衡器，总共可能需要5-10分钟。 我们通常会静默它所replace的服务器实例。 在同样的5-10分钟内，我们可能已经分了几十个新的服务器; 我们testing，但从来没有真正需要部署的。

我们将实例大小一直运行到高内存四倍超大实例，以实现最终的全峰负载。 我们考虑了更高CPU，更高networking带宽的Cluster Compute节点，但是由于它们需要不同的Linux版本（基于Red Hat / CentOS而不是Ubuntu的Amazon AMI），所以没有在那里部署，而且我们没有想要投资build设自动化或QA的第二个软件基础。

我们将S3用于文件，客户端通过CloudFront分发（即，S3通过CDN前端）访问它，以卸载I / O。 依靠这些数字，积极使用I / O卸载是我们所做的最重要的事情。 这也是最简单的。

我们尽可能地优化/缩小了WP主题和插件的JS，CSS和PHP文件。 这种变化玩弄破坏代码，所以我们使用Mercurial来跟踪变化，并立即退出所有破坏网站的变化。 不幸的是，devise者们select了一些图片库的插件，并且显示了当你每小时得到50个请求时很棒的Twitter feed，但是在缩放configuration上并不好，直接通过你的CPU和Twitter API分配。 严重的是，Twitter不希望你每秒钟敲门100次！ 无法find保证可伸缩性的Twitter提要插件或服务，我写了自己的简单caching机制。 我们不能修改图像库，至less要以微妙的方式改变外观，所以我们只是购买了更多的CPU来弥补其糟糕的devise。 （下一次：devise师，请select一个只使用JS，而不是PHP！）

我们使用YSlow，FireBug和Google Chrome的开发工具来指导优化过程。

我们使用了W3 TotalCache来减less站点负载。 不幸的是，网站devise与完全caching不兼容（打破了一些插件）。 我们没有时间来解决这些问题，所以我们将caching限制在可以安全完成的地方，再次购买了更多的CPU时间来弥补。

大多数自动化是通过Bash shell脚本或使用优秀的Boto模块/ API的Python程序完成的。 我们考虑过使用像Fabric，Chef和Salt这样的更高级的configuration启动器，但是我们遇到的各种小故障都说“我们很棒，但回来后再试一次，好吗？

结果非常好。 我们从来没有下过，也从来没有在负荷下徘徊。 我们已经准备好，可以处理我们收到的负载的5倍或50倍。 有很多事情我们可以做得更加优雅。 其中一些对于具有不同要求的服务是可取的甚至是必要的 – 例如，在较长的时间范围内的高负载，更大的负载变化或不可预知的尖峰等等。但是许多KISS权衡运作良好，通过适度DevOps得到实际胜利努力和低执行成本。

我最大的遗憾是我们没有自动化检测内容变化的过程，并在整个车队中进行复制。 我们需要网站运营商和内容所有者之间的手动协调 这个工作很好，考虑到短峰窗口 – 但它是繁重的。 如果我把这一切都完成了，那么看着大师进行文件/数据库更改，并在整个车队中自动启动复制过程将是＃1升级。 （这样可以大大提高企业的扩展能力，从而可以使用更小，更便宜的服务器实例，自动扩展configuration将会得到更高的利用率）。