WordPress可扩展性如何？

#1 楼

显然，快速Web服务器提供的静态文件无法缩放，而且任何必须弄清楚要加载什么然后再加载的CMS都无法正常运行，无论是WordPress还是其他方式。问题之一是每个URL请求所需的数据库查询的数量，以及我之前在Drupal专门工作的2年经验以及现在在WordPress已有2年以上的经验，这就是WordPress在该部门中要好得多。说，几乎没有任何力量可以“开箱即用”扩展；这就是随着可扩展性需求的增长该怎么办？

在“大量流量”的低端，有出色的缓存插件和与廉价CDN的集成，您可以在无IT预算和低托管预算的情况下做得很好。以下是一些其他要审查的问题和答案：


关于服务器负载优化WordPress的步骤？用于Amazon CloudFront缓存的WordPress吗？

是否有用于性能识别的性能分析选项：
一旦发现瓶颈，您就可以使用Transients API之类的工具进行本地化优化。该问答提供了一个可以使用Transients API进行优化的示例，并说明了如何：


使用WP_Query查询每个类别中具有受限帖子的多个类别？事情真的变得想拔出大手笔，您可以配置Memcached，HyperDB，Nginx和/或其他功能来加快工作速度（似乎后者实际上正在演变为从WordPress获得惊人的可扩展性的方式）：



为您的WordPress启用Memcached
如何使用Nginx和WP Super Cache加速WordPress

HyperDB
Nginx作为前端- WordPress的最终代理缓存

最后，出现了专门针对性能的新兴的以WordPress为中心的Web主机，例如WP Engine，ZippyKid等： />
所以好消息是所有尺度都很好。从技术的复杂性和成本的漫长而漫长的时间开始，随着流量的显着增长而增加。从WordPress开始，它会很棒。如果您的流量确实增加了，并且您将其合理地货币化，您会发现按需扩展具有很大的成本效益。 :)

#2 楼

不要对共享托管寄予太大期望-如果您在共享主机上，不要怪WordPress的速度慢。共享主机可能会将数千个帐户塞进一台服务器。因此，您可以花一整天的时间优化每月10美元的帐户，这无关紧要。还要提防市场流行语-只是因为它说“云”并不意味着您不会与数百或数千人共享一台服务器。
目前我认为不需要缓存插件。如果您查看WP源代码，那么核心中已经包含了高级缓存。缓存的缓存缓存的缓存-提防，这可能适得其反。
让您慢下来的主要原因是MySQL查询速度慢，开箱即用的WordPress不会给您带来麻烦。但是，我必须“限制”我的评论查询，因为我有50,000多个评论。 （这个问题解决了吗？）此外，如果您做的是非典型的事情（例如几千个类别？），也可能是一个问题。每个请求的工作时间不到1/100秒。几乎所有CPU时间都与MySQL捆绑在一起。您可以使用20美元的Linode每月提供一百万页的服务，但是一旦您开始添加插件和照片，我想您将需要一个“ 1GB” Linode。从我的角度来看，这几乎是线性的：如果网页浏览量增加了一倍，则只需将Linode的大小增加一倍。

免责声明：我不为Linode工作。


更新（大约2年后），因为您要使用PHP来缓存页面的某些部分，所以我使用的这是一个简单的解决方案，它出奇的快。我在1/100秒内将每页几个单独的部分/部分缓存。好像是ramdisk可以使速度更快，但是对于我的需求来说速度足够快：

#3 楼

最终，有3件事会导致WordPress大规模减速，其归结为：


托管堆栈-您需要使用最新软件的优质主机-PHP 7，Nginx，Varnish ，Redis，fail2ban和PerconaDB都是不错的选择
没有表扫描-许多插件都是由业余编码人员编写的，他们甚至都不知道表扫描是什么。避免表扫描需要做两件事-可用索引和以可以使用索引的方式编写的查询
PHP循环内没有或只有很少的SQL查询-某些插件代码显然仅在小型站点上进行了测试，由于某种原因，它将遍历数据库中的每个产品，并对每个产品/帖子进行新的SQL调用。理想情况下，您希望每页少于100条SQL查询-听起来很多，但实际上并没有，如果<100，您将获得大约200ms的TTFB未被缓存。然后，您可以添加缓存-例如清漆，CDN，页面缓存等。

如果需要扩展，可以使用PerconaDB XtraDB创建数据库，并使用Unison创建文件。这样，您可以有1个节点作为wp-admin和cron运行程序，其他节点为负载均衡器后面的Web流量提供服务。