在过去的几个月里，我们感觉自己的网站（wpml.org）运行速度变慢了。起初，我们采取了升级服务器这种简单粗暴的方法。但这并没有起效，于是我们开始集中精力认真分析问题。最终的成果就是今天的版本，它将我们的 CPU 负载和响应时间降低了 70%。
我们在性能分析方面学到了什么
性能对我们来说一直非常重要。多年来，我们一直在测试 WPML 的内存、查询和 CPU 时间，并在每次发布时对其进行改进。我们从这一轮开发中学到的是，静态测试并不总能发现真正的问题。
到目前为止，我们用于测试性能的方法是：
- 创建一个包含大量文章、文章元数据、类别和用户的大型数据库
- 生成一个“较重”页面的列表
- 多次加载它们，测量加载所需的时间，并进行分析
这向我们展示了需要调试和优化的前端和管理后台页面。我们确保减少查询次数、避免长查询并编写高效的 PHP 代码。
那么，遗漏了什么？
WordPress 和 WPML 比“请求页面并等待其加载”要复杂一些。一切都通过数据库进行，而数据库是一种共享资源。访客 A 在数据库中执行的操作可能会影响访客 B 获得的体验。
为了了解这些瓶颈，我们在生产站点上安装了一个名为 Appoptics 的工具。它使我们能够测量哪些函数和查询占用了时间，从而分析原因。
实际的性能提升
我们发现，字符串翻译中一个看似无害的操作与另一个插件对 options 表的频繁查询存在严重的资源冲突。如果您只运行该调用 100 万次，您不会感觉到任何问题。然而，当其他页面需要访问 options 表时，它们必须等待，直到字符串不再访问它。待处理请求的列表不断增加，导致数据库溢出，从而引发全面崩溃。
查看图表，您可以看到我们服务器的大部分精力都花在了数据库上（那个不断锁定和解锁的表）。您大概能猜到我们是在什么时间应用了修复程序。
但我还有其他性能问题，你们能修复吗？
我们发现的问题肯定不仅有助于 wpml.org，也有助于许多其他运行 WPML 的繁忙网站。如果您的网站负载非常小，您几乎感觉不到这种改进。它只影响并发量大且用户在执行许多不同操作的网站。
其他网站可能还可以使用其他性能优化。现在我们了解到，开展这项工作的最佳方式是在性能不佳的真实生产站点上安装分析工具。即使我们收到了您数据库的副本，我们也无法模拟您的流量。这就是为什么我们之前的所有测试都没有发现这个特定问题。
顺便说一下，我们的性能改进不仅发现了 WPML 中的瓶颈。我们修复了在 WPML 中发现的问题，但我们也注意到了其他地方的严重问题。其中一些我们自己打了补丁，另一些我们通过数据库进行了优化。
如果您感兴趣，请告诉我们，我们将帮助您在生产站点上安装性能分析工具。然后，我们将非常乐意帮助您分析结果。如果我们在 WPML 中发现任何问题，我们都会进行修复。存在性能问题的网站很有可能会发现许多来自意想不到来源的问题。
WPML 4.2.6 的其他新功能
WPML 核心 4.2.6
- 添加了 wpml_post_edit_meta_box_priority 过滤器，以更改 WPML 的文章编辑元数据框优先级
- 修复了在子文件夹安装情况下升级插件的问题 – 始终使用站点 URL
- 仅在需要时保存通知，以减少对 wp_options 表的额外写入
- 修复了语言切换器链接的安全问题
WPML 字符串翻译 2.10.4
- 修复了 ST mo 文件导入的问题，以免不必要地更新 wp_option 表
WPML 翻译管理 2.8.5
- 改进了翻译作业页面中分页控件的样式
- 修复了当管理后台语言不是英语时，翻译作业页面中分配译员的问题
- 修复了当管理后台语言不是英语时，“由...翻译”列内容不正确的问题
WPML Media Translation 2.5.2
- 仅在需要时保存通知，以减少对 wp_options 表的额外写入
WPML CMS Nav 1.5.1
- 通过仅在适用时清除缓存来提高性能
下载与更新
一如既往，您的所有注册站点都将自动收到此更新。您随时可以登录您的 WPML 账户进行手动下载和安装。
我们建议在更新网站上的任何内容之前进行备份。
反馈？问题？建议？
我们的网站现在运行速度快多了，但我们也很想了解您的网站情况。请留下您的评论，我们会给您回复。
