慢load_plugin_textdomain和load_default_textdomain

Question

我在我的主机上安装了Wordpress，速度非常慢。 （3s页面生成）。然后我将Wordpress安装到localhost并且性能相同。我使用xDebug来找出瓶颈是什么。差不多60％的时间花费load_plugin_textdomain和load_default_textdomain。我不知道为什么。有人可以帮帮我吗？

，文件位于网址：http://data.im-art.cz/cs_CZ.mo，http://data.im-art.cz/cs_CZ.po

由于

Answer 1

<强> TL; DR

确保在生产中禁用XDebug并缓存您网站的前端。

您的分析结果是在启用XDebug的情况下完成的（因为它们必须是这样）。看绝对速度是误导，因为XDebug本身就是它们变慢的原因。

在我五岁的Macbook Pro上，我得到的结果几乎和你一模一样。从cs_CZ.mo文件加载翻译大约需要1.4秒。如果我禁用分析，这会下降到88毫秒。 （大约x16快）。如果我完全禁用XDebug，则会降低到30毫秒（大约快47倍）。

所以我关于你的慢页面加载的第一个问题是 - 是否在生产中启用了XDebug ？如果是，请将其关闭。

如果你没有启用XDebug并且你的页面加载速度很慢，我认为无聊的答案是尽可能地缓存你的页面。有很多插件可以做到这一点。就个人而言，我的整个网站都在Cloudflare之后。流量几乎没有达到我自己的服务器。

尽管分析速度很慢，但毫无疑问瓶颈仍然是瓶颈，但是当你在每个页面视图上加载数千个翻译时，这并不奇怪。即使每个几十毫秒，也可以加起来。

您无法重写WordPress功能。只要他们采取，他们就会采取。但也许你可以改进磁盘I / O.深入研究MO::import_from_reader方法，看起来大约40％的时间花在PHP代码之外（即可能读取打开的文件）。提供SSD的托管服务提供商可能会给你带来提升，但我已经达成了。我认为缓存是最佳途径。

Answer 2

load_default_textdomain和load_plugin_textdomain的大量成本（使用cachegrind的术语）在WordPress中已为人所共知，并且效率低下。其他探查器也确实同意该主题，并且根据具体情况，他们可以轻松地将页面总加载时间加倍：

https://core.trac.wordpress.org/ticket/32052

简化：在非英语安装的每个页面加载中，WordPress确实将翻译文件加载并解析到内存中，但是在页面加载后丢弃解析的信息。这种加载/解析操作会占用大量CPU，并且会花费大量时间。

那些翻译文件曾经是纯文本文件（.po），但后来转移到编译的二进制文件（.mo），以某种方式减轻了开销。但是，即使到今天，按照“成本”（使用cachegrind的术语），它仍然约为35-40％。

周围有一些（鲜为人知的）插件可以通过缓存解析的翻译来“修复”此问题：

• https://de.wordpress.org/plugins/fast-translate/
• https://de.wordpress.org/plugins/mo-cache/
• https://de.wordpress.org/plugins/speed-up-translation/
• https://github.com/inpsyde/translation-cache
• https://www.bjornjohansen.com/wordpress-translations-loading-time

...只是该主题的一些示例和更深入的研究。

那些插件通常确实将默认例程替换为一个包含缓存的例程，并且在解析未缓存的数据时通常也更有效。通常使用WP的对象缓存API将缓存的信息存储为临时缓存数据。除非有可用的特殊软件（如Memcached或Redis）以及某些Object Cache插件来将瞬态API与这些服务接口，否则WordPress默认情况下会将瞬态数据存储在其自己的MySQL数据库中。

由于大多数托管服务提供商确实提供了联网的MySQL服务器，因此可能会不小心用网络密集型操作代替CPU密集型操作，而用另一种原因代替了导致页面加载时间较长的一种原因。如果您的WordPress确实可以访问本地Redis或Memcache实例，则可以尝试上述插件。

虽然通常建议使用PHP的OPcache，但不会带来太多好处：OPcache确实编译并缓存了PHP源代码，但是执行缓存的源代码以解析翻译文件仍然和不使用OPcache一样昂贵。

迁移到基于SSD的托管也没有改善：受影响的文件正在为每个页面视图加载，因此它们非常频繁地使用，并且很可能从内核的缓冲区高速缓存中提供，而无需任何形式的读取操作文件系统或块设备。

缓存“一次执行”的PHP输出（通过使用特殊的缓存插件，CDN或诸如nginx fastcgi缓存之类的模块）确实可以将任何效率低下的地方隐藏在其他WordPress插件或WP Core中。根据确切的解决方案和部署，使此类缓存的内容无效可能会变得非常棘手。