Manual:Performance tuning/zh

本页概述了各种改进 MediaWiki 性能的方法.

概要
MediaWiki 能够扩展以满足大型维基农场的需求，例如 Wikimedia Foundation、WikiHow 和 Fandom，并且可以利用多种方法，包括多个负载平衡数据库服务器， Memcached 对象缓存，Varnish 缓存（参见 手册:Varnish 缓存）和多个应用服务器. 对于大多数较小的安装，这有点矫枉过正，只需启用对象缓存和优化 PHP 性能就足够了.



快速开始
简而言之，我们推荐 PHP 使用字节码缓存，APCu 作为本地对象缓存，Memcached 作为主缓存；这就是维基媒体基金会用于维基百科等的配置.

在某些情况下，太多层的过度缓存可能会降低性能.



使用 Puppet 快速开始
此页面上的大部分调整已收集在 Puppet 清单中（ 和 ）. 如果你安装 Puppet，你可以用一个命令将它们应用到你的服务器.

PHP


字节码缓存

 * 请参阅 PHP 配置#Opcode 缓存.

PHP 通过将 PHP 文件编译成字节码然后执行该字节码来工作. 编译大型应用程序（如 MediaWiki）的过程需要相当长的时间. PHP 加速器通过存储编译的字节码并直接执行它来工作，减少了编译代码所花费的时间.

OPcache 包含在 PHP 5.5.0 及更高版本中，是 MediaWiki 推荐的加速器. 其他支持的操作码缓存有：WinCache.

Opcode 缓存存储 PHP 脚本的编译输出，大大减少了多次运行脚本所需的时间. MediaWiki 不需要特别配置来执行 PHP 字节码缓存，一旦安装并启用它们就会“正常工作”.

从 MediaWiki 1.36 开始，在没有字节码缓存的系统上它可能会变慢. 参见.



对象缓存
有关本地服务器、主缓存和其他缓存接口的更多信息，请参阅手册:缓存.



本地服务器
此接口用于直接在 Web 服务器上进行轻量级缓存. 此接口可以跨 Web 请求持久保存存储的值.

MediaWiki 会自动检测是否存在支持的后端. '''不需要特别配置 MediaWiki. '''

对于 PHP 7+，您应该安装 APCu 或 WinCache. (在 PHP 5 上，已知 APCu 在某些情况下不稳定. )

要安装 APCu，请使用：

脚本  与 APCu 包捆绑在一起，可用于检查缓存的状态，并检查用户缓存的内容以验证 MediaWiki 是否正确使用它.



主缓存
这个接口被用作较大对象的主要对象缓存.

主缓存默认是禁用的，需要手动配置. 要启用它，请将 设置为  中的一个键. 有为 Memcached、APC 和 MySQL 预先配置的接口. 你可以通过 配置其他类型的后端（例如 Redis）.



单个 Web 服务器
如果您安装了 APC，强烈建议通过在 中设置以下内容来使用它：

一旦设置，用户会话存储和解析器输出缓存也将继承此 MainCacheType 设置.

在内存有限（且未配置 Memcached 或其他对象缓存）的情况下使用 APC 时，由于解析器输出缓存的大小不断增加，重要对象可能会被过于频繁地逐出. 考虑将 设置为 CACHE_DB，这会将这些键移出到数据库中.

如果使用  并且用户由于“会话劫持”错误而无法登录，请考虑将  覆盖为. 有关详细信息，请参阅任务 T147161.

如果您不能使用 APC，请考虑安装 （至少需要 80MB 的内存）. 虽然安装 Memcached 要复杂得多，但它却非常奏效.

如果 APC 或 Memcached 二者都不选，您可以退回到将对象缓存存储在你的数据库中. 下面的预设将做到这一点：



多个 Web 服务器
如果您的 MediaWiki 站点由多个 Web 服务器提供服务，您应该使用中央 Memcached 服务器. 详细说明在  页面上.

如果您有多个 Web 服务器，请务必不要将 APC 用作主缓存. 此缓存必须针对单个 MediaWiki 安装进行集中协调. 让每个 Web 服务器都使用 APC 作为自己的主缓存会导致陈旧的值、损坏或其他意外的副作用. 请注意，对于可以安全地以非协调方式存储的值（“本地服务器缓存”），无论此配置设置如何，MediaWiki 都会自动使用 APC.



跨维基缓存
MediaWiki 跨维基前缀存储在  数据库表中. 有关如何启用缓存的信息，请参阅.



本地化缓存
默认情况下，接口消息翻译缓存在 数据库表中. 确保将 中的  设置为有效路径以改为使用本地缓存. 参见帮助:系统消息#缓存了解更多细节.

Sidebar cache
A small save in DB queries can be obtained by caching the sidebar (disabled by default). See  and.



页面访问缓存
页面访问缓存极大地提高了匿名（未登录）用户的性能. 它不会影响登录用户的性能.



缓存代理
缓存代理（或“HTTP 加速器”）存储由您的网络服务器生成的网页副本. 当第二次请求此类页面时，代理会提供其本地副本，而不是将请求传递到真实的 Web 服务器.

这极大地改善了最终用户对页面加载的响应时间，并且还极大地减少了 MediaWiki 网络服务器上的计算负载. 编辑页面时，MediaWiki 可以自动从缓存代理中清除本地副本.

缓存代理的示例：
 * Varnish Cache，目前（截至 2018 年 11 月）由维基百科使用. 另见手册:Varnish 缓存.
 * Squid，这是维基百科在 2012 年之前使用的.
 * Apache 的 mod_cache_disk，请参阅 这篇文章 以了解 MediaWiki 的说明.



文件缓存

 * 有关此内容的主要文章，请参阅.

在没有缓存代理或 HTTP 加速器的情况下，MediaWiki 可以选择使用文件系统来存储渲染页面的输出. 对于较大的站点，使用像 Varnish 这样的外部缓存比使用文件缓存更可取.



Web 服务器

 * 如果您使用 Apache 作为 Web 服务器，请使用 PHP-FPM，而不是 mod_php. PHP-FPM 优化了 PHP 进程的重用.
 * 将 Apache 切换为使用事件 MPM 而不是 prefork MPM.
 * 调整 robots.txt 以禁止机器人抓取历史页面. 这将减少一般的服务器负载.
 * HTTP/2 协议可以提供帮助，即使是 ResourceLoader.



配置设置
运行 MediaWiki 1.6 或更高版本的大型站点应将 设置为较低的数字，例如 0.01. 参见 以获取更多信息.

Composer
MediaWiki 使用 Composer 来组织库依赖项. 默认情况下，这些是使用动态自动加载器从  目录中包含的. 这个自动加载器需要搜索目录，这一过程可能会比较缓慢. 建议使用 Composer 生成静态的自动加载器，这将使您的 wiki 响应更快.

使用静态的自动加载器是所有从 tarball 下载或 Git 安装的 MediaWiki 的默认设置. 如果由于某种原因导致不是这种情况，请使用以下命令生成静态自动加载器：

composer update -o --no-dev

请记住，这需要在每次 MediaWiki 更新后重新运行，因为它包含软件中存在的库和类的静态副本.



MySQL
对于繁重的并发写入负载，InnoDB 是必不可少的. 使用 Memcached，而不是默认的基于 MySQL 的对象缓存.

请参阅下面的一些数据库配置技巧. 您也可以尝试运行 mysql-tuning-primer 脚本来快速获得一些统计数据和建议.

<span id="Multiple_servers">

多个服务器
数据库软件和网络服务器软件将开始争夺托管在单个服务器上的繁忙 MediaWiki 安装上的的内存. 如果您的 wiki 具有稳定的流量，那么在进行了其他性能优化（并且对大部分内容提供缓存）后，一个合乎逻辑的步骤是将数据库和 Web 服务器放在单独的服务器上（或者，在某些情况下，多个单独的服务器，从副本开始. ） 此外：


 * 检查 MySQL 是否启用了查询缓存和足够的内存；
 * 将大部分内存分配给 innodb_buffer_pool；
 * 如果在高峰时间达到最大值，则为 MySQL 添加核心；
 * 为 Memcached 提供更多内存.

基准测试
一些工具可以帮助快速评估性能调整的效果.


 * http://webpagetest.org 是“现实生活”测试，可在您的浏览器中执行.
 * ab 是一个命令行工具，可以快速生成一些不错的统计数据.
 * PageSpeed

<span id="See_also">

参见

 * http://dammit.lt/2007/01/26/mediawiki-performance-tuning/ : APC 和一些提高性能的简单设置
 * 更激进的牺牲部分功能的修改
 * 如何给 MediaWiki 提速
 * Comprehensive MediaWiki performance optimisation (mostly redundant with this page and what above)
 * User:Ilmari Karonen/Performance tuning, focusing on small wikis
 * Use cases:
 * Wikipedia: Site internals, configuration, code examples and management issues [PDF, 2007]
 * Caching, minification, domain-sharing and compression techniques used by WikiFur
 * For developers:
 * Logging and
 * North's Performance chapter
 * Wikimedia specific documentation:
 * Backend performance guide of the Wikimedia Performance Team
 * Frontend performance guide of the Wikimedia Performance Team