将WordPress REST API性能与admin-ajax.php进行比较

研究典型的REST请求以及提出的类似请求admin-ajax.php以了解它们之间的比较情况

自引入WordPress REST API以来，许多插件开发人员已开始将其插件转换为使用REST API而不是较旧的AJAX API（admin-ajax.php）。除了REST API只是一种较新的技术外，有传言说REST API也比旧的端点更快，更可靠，原因是在典型的REST请求期间没有加载太多的WordPress。

在本文中，我们将研究典型的REST请求以及提出的类似请求admin-ajax.php以了解它们之间的比较情况。

原文来源于：详情

将WordPress REST API性能与admin-ajax.php进行比较

admin-ajax.php请求的寿命

让我们首先分解一下当我们向发出典型的AJAX请求时会发生什么admin-ajax.php。当您的浏览器对该文件发出请求时，它会加载其他一些核心WordPress文件，以便能够在加载了核心功能的情况下满足请求：

/wp-load.php
/wp-config.php
/wp-settings.php （它会加载大多数核心文件，所有活动的插件和主题以及REST API）
/wp-admin/admin.php
/wp-admin/includes/ajax-actions.php

加载这些文件后，WordPress将调用该admin_init挂钩，几个核心功能都将挂钩。在WordPress 4.5.3的此钩子上调用了以下核心功能：

register_admin_color_schemes
send_frame_options_header
_wp_check_for_scheduled_split_terms
_wp_admin_bar_init
_maybe_update_core
_maybe_update_plugins
_maybe_update_themes

调用完这些函数后，WordPress最终将调用$_GET[‘action’]或$_POST[‘action’]变量中提供的AJAX操作。

REST API请求的生命周期

与admin-ajax.php请求相比，典型的REST请求看起来略有不同。由于REST端点是由WordPress重写API处理的，因此请求将传递到/index.php，然后正常加载其余WordPress。

/index.php
/wp-blog-header.php
/wp-load.php
/wp-config.php
/wp-settings.php （它会加载大多数核心文件，所有活动的插件和主题以及REST API）

与发送过来的请求不同admin-ajax.php，REST API不会通过加载WordPress管理部分/wp-admin/admin.php，也不会触发admin_init动作挂钩。基于此，任何不依赖于管理员特定功能（但使用admin-ajax.php）的插件或主题都可能会通过切换到REST API来获得轻微的性能提升。

基准测试

既然我们已经看到了幕后发生的事情，那么让我们建立一个可以轻松进行基准测试的场景。为此，我们将创建一个可以在admin-ajax.php或REST API上运行的简单函数：

function benchmark_request() {
    $result = array( 'time' => time() );
    echo json_encode( $result );
    exit;
}

add_action( 'wp_ajax_benchmark_request', 'benchmark_request' );
add_action( 'rest_api_init', function() {
    register_rest_route( 'benchmark/v1', '/benchmark/', array(
        'methods'  => 'POST',
        'callback' => 'benchmark_request'
   ) );
} );

上面的函数只是返回JSON中的时间-这只会有助于使您更容易看到请求没有被缓存。

为了执行实际的基准测试，我们将使用ApacheBench，这是一个命令行基准测试工具，它使您可以一次触发多个请求以了解服务器的性能。

让我们admin-ajax.php先测试版本。

 ab -n 100 -c 1 -p ~/Desktop/post.data -g ~/Desktop/ajax.tsv -T application/x-www-form-urlencoded http://localhost/rest-api/wp-admin/admin-ajax.php

上面的命令将100个POST请求发送到该/wp-admin/admin-ajax.php文件并记录响应时间。post.data引用的文件只是一个文本文件，其中包含要与请求一起发送的URL编码的$ _POST值（在本例中为action=benchmark_request）。

在100个请求下，在MAMP和PHP 7上全新安装WordPress且未激活其他插件的情况下，平均响应时间为253ms。这为基于REST API的相同测试提供了良好的基准：

ab -n 100 -c 1 -p ~/Desktop/post.data -g ~/Desktop/rest.tsv -T application/x-www-form-urlencoded http://loc

毫不奇怪，在此比较中，REST API的速度稍快，在100个请求中的平均响应时间为217ms。显然，这并不是一个很大的差异，REST API仅比传统的AJAX API快15％，但是在许多请求中，这种微小的差异肯定会加起来，尤其是当添加了更多插件时。

让我们运行相同的基准测试，但激活一些插件。对于这些测试，我激活了一些常见的插件，您可能会在典型的网站上找到它们：

ACF
Akismet
Black Studio TinyMCE小工具
WP迁移数据库
WP超级缓存
Yoast SEO

尽管总体响应时间有所增加，但admin-ajax.php和REST API之间的性能差距仍然大致相同。随着额外的插件加载，REST API，将约16％的速度，并有一个平均响应时间490ms相比567ms以上admin-ajax.php：

具有大量插件的网站可以通过REST API看到更大的性能提升，但这完全取决于正在运行哪些插件以及如何对其进行编码。

因此，您应该使用WordPress REST API吗？

从性能的角度来看，显然有一点优势。添加自定义API端点非常简单，并且由于不必加载太多WordPress核心（包括管理区域和常用admin_init钩子），因此它admin-ajax.php在大多数情况下可能会比使用更快。

在可靠性方面，REST API仍取决于活动插件或主题的质量和完整性。编码不良的插件仍可能轻易干扰REST请求，尤其是将来有更多插件采用REST API时。但是，由于使用REST API的插件较少，因此目前应该更可靠。

总体而言，至少考虑使用REST API绝对是一个好主意。添加自定义API端点非常简单，并且切换现有代码也不需要很多。

{{userData.name}}已认证