适用于高容量网站的可扩展 WordPress 主机?

适用于高容量网站的可扩展 WordPress 主机?

我需要为高流量 WordPress 网站推荐一个可扩展的 Web 主机。就我而言,高流量可能是每小时 10 万到 50 万访问者。可能认为每小时 100 万的突发速率是“最高水位线”。

我知道 WP 并不是性能最高的平台(哈哈!),但这是没有商量余地的。我可以进行“常规优化”(例如,将静态文件放入 CDN,运行并遵循 YSlow 等性能分析器的建议)。但它仍然是 WordPress,并且会涉及十几个插件。

那么,在哪里托管网站?大多数“最好的 WordPress 主机是什么?”讨论似乎都集中在最低成本上。我需要相反的。您使用过哪些高容量、可扩展或集群的 WordPress 主机,体验非常好?

答案1

Dedicated, Dedicated, Dedicated, Dedicated </steveballmer>

好的,我已经把这个问题说出来。如果我认真考虑一个流量如此之高的网站,那么每小时 500khits 确实是一个很大的数字。

我真的真的考虑构建自己的网络和集群来托管它。我可能会从 4 节点系统开始。2 个前端正在运行Varnish 缓存,以及 2 个后端,分别运行 Apache 和 MySQL。在后端之间进行循环复制,并运行 memcached 进行会话同步。

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

我非常担心虚拟服务器上的高流量网站。主要是因为 IO 性能,但也因为它可能对同一服务器上其他虚拟机的性能造成很大损害,这可能不是你关心的问题,但它确实意味着其他人的流量可能会干扰你的网站。

WP 并不像你想象的那么糟糕。你必须进行大量优化,媒体使用无 cookie 域,你提到的所有事情都会有所帮助。你将需要 2 层缓存,或者也许 3/4 层。CDN、ReverseProxy 缓存,也可能受益于使用 memcache 的查询缓存,以及使用 APC 的操作码缓存。

可以进行许多小的优化,这将大大提高性能,并且都值得研究。

VarnishCache 不仅是一款出色的反向代理缓存,而且还是一款非常出色的负载平衡器,相信我,您会想要多个后端服务器。如果您的网站很重要,并且正常运行时间对您来说很重要(它会为您带来收入吗?),那么您肯定会想要多个服务器。

仔细想想,如果您要提供大量的媒体资产、图像等,我肯定会考虑另外几台服务器,可能运行 nginx 而不是 apache,服务 media.yourdomain.com,或者完全不同的无 cookie 域,例如 stackexchange 网站上使用的 sstatic.net 域。

这是一个如何操作的示例,但您必须将 RFC1918 范围之外的 IP 地址更改为可公开路由的 IP 地址;)

示例服务器配置

我要在有人抱怨多条 A 记录之前就把这个问题扼杀在萌芽状态。无需深入到第 3 层,也无需使用 BGP 或 GS​​LB 实现高可用性,使用循环 DNS 进行非智能负载平衡是一种不错的方法,成本不高,实际上,相比之下非常便宜。您可以使用以下服务实现稍微更智能的 DNS戴奈特,它将在将请求发送到您的负载均衡器之前执行一定级别的主机检查。

如果您选择一家优质的专用服务器主机,他们可能会为您完成上述部分或全部工作。考虑到您预计会有相当多的流量,我可以很容易地说,廉价的专用服务器(每月不到 200-300 美元)很可能是一种虚假的经济,无法支持您预期的流量水平。

答案2

赛义德卡里姆 :“您最终在哪里/如何托管该网站...”因此,这里是我的“前端笔记”:

我没有找到任何“自动化”服务或解决方案。Wordpress.com VIP Hosting、WP Engine 和其他一些服务看起来相当有趣,但不符合这个要求。所以我们直接在 Amazon Web Services (AWS) 上托管。

我们使用了(一些大型的)EC2 服务器实例 + 弹性负载均衡器 + S3/CloudFront I/O 卸载 + 优化/最小化 + 缓存 + CloudWatch 监控 + SNS 通知 + Python/bash 自动化/脚本 + 基于 Mercurial 的复制。

TL;DR 详细信息:

该网站是一个快闪活动网站,活动人数超过 100 万。活动开始前 15 天,该网站的访问量只有名义上的,但随后在 T-3 天左右开始加速,进入急剧上升阶段。使用 Google Analytics 或网站性能监视器,您可以看到负载每小时显著增加。

我们使用了 EC2 服务器,运行 Ubuntu“Natty Narwhal”、MySQL 5.1 和 WordPress 3.x。它们由 Elastic Load Balancer 负责前端。我们必须将 DNS 转移到 Amazon 的 Route 53 服务,以使 ELB 与我们的主域(例如 domain.tld 而不是 www.domain.tld)正常工作。

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

在此配置下,最终一致性 <= ~3 分钟。也就是说,在内容更新后的几分钟内,部分用户仍可以看到旧内容。

在负载下,WordPress 需要 CPU 的速度比内存快得多,因此我们最终在内存上配置了过多的内存。但我们需要 CPU,而且价格/复杂性权衡对于我们处于高峰运行的有限小时数来说是正确的。

我们考虑了自动扩展配置,但了解到峰值负载的持续时间很短且可能的需求曲线,并且具有良好的性能指标和警报(从 CloudWatch 和 SNS 开始),我们选择了手动扩展 - 这是另一个成功的 KISS 选择。

最常见的扩展操作是激活下一个最大实例、自动加载所需软件、自动复制网站内容并将其添加到 ELB 组。从头开始,实例激活通常在 3 分钟内完成。在人工确认服务器运行正常并将其添加到负载均衡器后,扩展总共可能需要 5-10 分钟。我们通常会让它替换的服务器实例处于静止状态。在同样的 5-10 分钟内,我们可以启动几十台新服务器;我们进行了测试,但实际上从未需要部署它。

我们运行的实例大小一直到高内存四倍超大实例,以实现最终的全峰值负载。我们考虑过更高 CPU、更高网络带宽的集群计算节点,但没有在那里部署,因为它们需要不同的 Linux 版本(Amazon AMI,基于 Red Hat/CentOS 而不是 Ubuntu),而且我们不想为第二个软件基础投资构建自动化或 QA。

我们使用 S3 存储文件,客户端通过 CloudFront 分发(即通过 CDN 前端的 S3)访问文件,以卸载 I/O。从数据来看,积极使用 I/O 卸载是我们做的最重要的事情。这也是最简单的。

我们尽可能优化/压缩了 WP 主题和插件的 JS、CSS 和 PHP 文件。这样的更改可能会破坏代码,因此我们使用 Mercurial 来跟踪更改,并立即撤消任何破坏网站的更改。不幸的是,设计师选择了一些用于图片库和显示 Twitter 源的插件,这些插件在您每小时收到 50 个请求时效果很好,但在扩展配置中效果不佳,会直接耗尽您的 CPU 和 Twitter API 配额。说真的,Twitter 不希望您每秒敲他们的门 100 多次!由于找不到保证可扩展的 Twitter 源插件或服务,我编写了自己的简单缓存机制。如果不以至少微妙的方式改变外观,我们就无法修复图片库,所以我们只是购买了更多 CPU 来弥补其糟糕的设计。(下次:设计师,请选择一个只使用 JS 而不是 PHP 的!)

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

我们使用了 W3 TotalCache 来减少网站负载。不幸的是,网站设计与完全缓存不兼容(破坏了一些插件)。我们没有时间修复这些问题,因此我们将缓存限制在可以安全完成的范围内,并再次购买了更多的 CPU 时间来弥补。

大部分自动化操作都是通过 Bash shell 脚本或 Python 程序使用出色的 Boto 模块/API 实现的。我们考虑过使用更高级的配置启用程序,如 Fabric、Chef 和 Salt,但我们遇到的各种故障都说“我们很棒,但稍后再回来尝试,好吗?”

结果非常好。我们从未宕机,也从未在负载下出现问题。我们已做好准备,并可以处理 5 倍或 50 倍的负载。我们本可以做得更优雅。其中一些对于具有不同要求的服务来说是可取的,甚至是必要的——例如,较长时间内的高负载、更大的负载变化或不可预测的峰值等。但许多 KISS 权衡效果很好,以适度的 DevOps 工作量和较低的执行成本取得了实际胜利。

我最大的遗憾是我们没有实现检测内容更改并在整个服务器群中复制这些更改的自动化。我们需要站点运营商和内容所有者之间的手动协调。考虑到高峰期很短,这种方法还行,但很繁重。如果我必须重来,监视主服务器的文件/数据库更改并自动启动整个服务器群的复制过程将是首要的升级。(这将带来第二个好处,即大大提高企业的横向扩展能力;然后我们可以使用更多更小、更便宜的服务器实例。然后,自动缩放配置将得到更高的利用率。)

答案3

VPS.net 是一种完全可扩展的解决方案,具有高容错性。它价格低廉,功能强大且灵活。MediaTemple 是另一个不错的提供商,因为您可以从功能较弱的虚拟机开始,然后只需单击一下按钮即可扩展到您自己的服务器。您应该寻找能够快速水平扩展(冗余/集群)和垂直扩展(更多存储/CPU/RAM)的提供商。

答案4

对于高容量 WordPress 托管,我会选择 WordPress VIP

WordPress VIP 托管在 WordPress.com 主干网上运行,该主干网在 3 个数据中心的 1200 台服务器之间实现负载平衡。

你得到什么:

  • 您的网站在 WordPress.com 网格上运行(三个数据中心有超过 1,200 台服务器)
  • 无限空间和带宽
  • 24/7 IT 支持
  • 内容交付网络和每小时备份
  • 企业级 Akismet 垃圾邮件防护
  • 对网站主题进行优化和安全反馈,以实现更快、更安全的网站
  • 与 WordPress.com 功能集成,例如每日博客、我的评论、Tag Surfer 和 Gravatars
  • 在我们的发布者博客上推广您的新博客
  • 网站地图和新闻网站地图可提高搜索引擎和 Google 新闻的曝光率
  • 登录 WordPress.com 的用户将登录您的域,这样他们就可以更轻松地对您的博客发表评论

成本

起薪约为每月 2,500 美元。

相关内容