WordPress Heartbeat APIの通信間隔は画面と処理内容を確認してから変える

WordPressのHeartbeat APIによる負荷を疑うときは、先に通信している画面、間隔、送信データ、サーバーの応答時間を確認します。投稿編集画面で15秒ごとに通信している場合と、ほかの管理画面で60秒ごとに通信している場合を、同じ設定で止めてはいけません。

Heartbeat APIは、投稿の編集ロックやログイン状態の確認に使われます。通信を止めれば要求数は減りますが、必要な機能まで止まります。間隔の調整は、遅い処理を特定したあとに行います。

まずaction=heartbeatの要求を確認する

ブラウザーの開発者ツールで管理画面の通信を開き、admin-ajax.phpへの要求を確認します。Heartbeat APIの要求には、action=heartbeat、screen_id、その画面やプラグインが追加したdataが送られます。

WordPress 3.8のサーバー処理にあるwp_ajax_heartbeat()は、nonceを検査し、画面IDとデータを受け取ります。その後、heartbeat_receivedとheartbeat_sendを通し、応答を返します。

一回の通信が遅い場合、間隔だけでなく、dataの中身と追加された処理を調べます。プラグインが毎回大きなデータを送り、サーバー側で重い処理を行っていれば、間隔を延ばしても原因は残ります。

調査では、次の四項目を同じ記録へ残します。

画面を移動して同じ記録を取り、どの画面で回数または応答時間が増えるかを比べます。

通常の60秒と投稿編集画面の15秒を分ける

WordPress 3.8のheartbeat.jsは、通常の通信間隔を60秒に設定します。初期設定で指定できる通常間隔は15秒から60秒で、必要な処理は一時的に5秒へ切り替えられます。

投稿編集画面では、post.jsが編集ロック用の画面を確認し、間隔を15秒へ設定します。別の利用者による上書きを防ぐため、編集状態を短い間隔で伝える必要があるからです。

したがって、投稿編集画面だけ15秒で通信していても、それだけで異常とは判断できません。複数人で編集するサイトでは、間隔を延ばす前に、編集ロックの更新が遅くなる影響を確認します。

heartbeat_settingsは初期値を変える

WordPress 3.8のスクリプト登録処理は、heartbeat_settingsフィルターを通した値をHeartbeat APIへ渡します。初期の通信間隔を60秒に指定するコードは、次のようになります。

function satolab_set_heartbeat_interval( $settings ) {
    $settings['interval'] = 60;

    return $settings;
}

add_filter(
    'heartbeat_settings',
    'satolab_set_heartbeat_interval'
);

このフィルターは初期値を渡します。画面側のJavaScriptがあとからwp.heartbeat.interval()を呼べば、その画面の目的に合わせた間隔へ変わります。投稿編集画面で15秒の通信が続く場合、フィルターが動いていないと即断せず、post.jsによる設定を確認します。

また、heartbeat.jsは15秒未満または60秒を超える初期値を、その範囲へ収めます。120秒を指定して通信を半減させる、といった調整にはなりません。

API全体を止める前に利用機能を確認する

Heartbeat APIをすべての管理画面から外すと、標準機能とプラグインの処理をまとめて失う可能性があります。少なくとも、次を確認します。

• 複数の利用者が同じ投稿を編集するか
• 投稿の編集ロックを使うか
• ログイン期限の通知を使うか
• プラグインやテーマがheartbeat-sendとheartbeat-tickを使うか
• 遅い通信が特定の画面とデータだけで起きるか

特定のプラグインが追加した処理だけが遅いなら、その処理を直すか、必要な画面だけで動かします。Heartbeat API全体の停止は、原因となる処理と関係のない画面まで変えてしまいます。

運用を制作会社へ委託している場合も、通信間隔を変えたコード、変更理由、確認した画面、元へ戻す条件をサイト側へ残します。負荷対策のコードが、編集作業の不具合として残らないようにします。

まず、開発者ツールでaction=heartbeatを一件開いてください。画面、間隔、送信データ、応答時間を記録し、遅い処理が見つかった場合だけ変更範囲を決めます。