説明
Docket Cache は、キャッシュデータをプレーンな PHP コードとして保存する WordPress 用の永続オブジェクトキャッシュです。Redis や Memcached を利用できないサイト向けの代替手段として設計されています。
ほとんどのファイルベースのキャッシュプラグインは、シリアライズとアンシリアライズを使用して PHP オブジェクトをフラットファイルに保存します。Docket Cache は、オブジェクトをプレーンな PHP コードに変換するという異なるアプローチを採用しています。これにより、特に Zend OPcache が有効な場合に、データの取得が高速になり、全体的なパフォーマンスが向上します。
詳細については、WordPress のキャッシュに関するドキュメンテーションを参照してください。
このプラグインを使用する理由はなんですか ?
WordPress で信頼性の高い永続オブジェクトキャッシュを実現するには、Redis や Memcached が最適な選択肢です。ただし、これらにはサーバーに関する知識が必要で、低価格のホスティングプランや共有ホスティングプランで利用できることはほとんどありません。
もう一つの方法は、オブジェクトキャッシュをファイルに保存することです。WordPress では、PHP オブジェクトのエクスポートは簡単ではありません。ほとんどのファイルベースのキャッシュプラグインは、データの保存と取得にオブジェクトのシリアライズとアンシリアライズを利用しています。
Docket Cache は、オブジェクトキャッシュをプレーンな PHP コードに変換することで、より優れたアプローチを採用しています。これは、WordPress が他の処理なしで直接キャッシュを使用できるため高速です。
特徴
- オブジェクトキャッシュ + OPcache
- 高度なポストキャッシュ
- オブジェクトキャッシュの Precache
- WordPress メニューのキャッシュ
- WordPress 翻訳キャッシュ
- WordPress コアクエリーの最適化
- タームカウントクエリーの最適化
- 投稿・固定ページ・コメント数の最適化
- データベーステーブルの最適化
- WooCommerce の最適化
- WP オプションの Autoload の停止
- ミスした予約の調整
- オブジェクトキャッシュと OPcache の統計 + OPcache ビューアー
- キャッシュログ
- Cronbot サービス
- WP-CLI のサポート
- マルチサイト / マルチネットワークのサポート
システム要件
Docket Cache を使用するための最小要件:
- PHP 7.2.5
- WordPress 5.4
また、以下も推奨します:
- Zend OPcache
Docket Cache はキャッシュを PHP ファイルとして保存するため、OPcache の有無にかかわらず動作します。OPcache を使用すると、PHP はこれらのファイルをすぐに使える状態でメモリ上に保持し、ページを読み込むたびにディスクから読み込む必要がなくなるため、キャッシュが大幅に高速化されます。
ドキュメンテーション
設定オプション、インストールガイド、コマンドラインでの使用方法については、ドキュメンテーションを参照してください。
開発
- GitHub リポジトリ — Docket Cache のソースコードと開発の拠点です。
- 変更履歴 — 変更、修正、改善の全履歴です。
- Gapo Tunnel — 安全なトンネルを通じてローカルサービスをインターネットに公開します。ローカル開発環境で Docket Cache をテストする際に便利です。
- WP Staging Desktop — 公開中の WordPress サイトを数分でローカル開発環境に変換します。
このプロジェクトのスポンサー
1 回限りまたは定期的なご支援で、Docket Cache の継続的な開発をサポートしてください。
主なスポンサー:
心より感謝申し上げます。
- Jimat Hosting
- Themecloud
- Websavers Inc
- Avunu LLC
- Linqru
- Gentleman’s Guru
- SecurePay
- DNSVault
- Exnano Creative
その他のスポンサーは名誉リストに掲載されています
スクリーンショット
インストール
Docket Cache には PHP 7.2.5 以上と WordPress 5.4 以上が必要です。また、最適なパフォーマンスを得るには Zend OPcache が必要です。
- WordPress の管理画面でプラグイン -> 新規追加に移動します。
- 「Docket Cache」を検索し、今すぐインストールをクリックします。
- 有効化をクリックします。マルチサイト環境の場合はネットワークで有効化をクリックします。
- 左側のメニューにある Docket Cache をクリックして、設定ページにアクセスします。
Docket Cache がオブジェクトのキャッシュを開始するまで、数秒お待ちください。
FAQ
-
WordPress のオブジェクトキャッシュとは何ですか ?
-
オブジェクトキャッシュは、データベースのクエリー結果を保存し、次に必要になったときにすばやく取得できるようにします。
キャッシュされたデータは、データベースへのクエリーを繰り返す代わりに、キャッシュから直接提供されます。これにより、サーバーの負荷が軽減され、サイトが高速になります。
簡単に言えば、オブジェクトキャッシュとは、頻繁に使用されるデータを、よりすばやくアクセスできる場所に保持する仕組みです。
-
オブジェクトキャッシュにおける Docket Cache の役割は何ですか ?
-
WordPress のオブジェクトキャッシュは、デフォルトでは非永続的です。つまり、キャッシュデータは 1 回のページリクエストの間だけメモリに保存され、ページの読み込みをまたいで保持されることはありません。永続化するには、オブジェクトキャッシュをディスクに保存する必要があります。
Docket Cache は、オブジェクトキャッシュを保存するだけでなく、キャッシュデータをプレーンな PHP コードに変換します。これは、WordPress が他の処理なしで直接キャッシュを使用できるため高速です。
-
Docket Cache における OPcache とは何ですか ?
-
OPcache は PHP に組み込まれたキャッシュエンジンです。プリコンパイルされたスクリプトのバイトコードを共有メモリに保存することで、PHP がリクエストごとにスクリプトを読み込んで解析する必要がなくなり、パフォーマンスが向上します。
Docket Cache は、オブジェクトキャッシュをプレーンな PHP コードに変換します。キャッシュデータの読み書き時に OPcache を直接使用するため、データの取得が高速になり、パフォーマンスが向上します。
-
Docket Cache の Cronbot サービスとは何ですか ?
-
Cronbot は、WordPress Cron を常に動作させるために、1 時間ごとにウェブサイトに Ping を送信する外部サービスです。
このサービスはオプションであり、必須ではありません。デフォルトではエンドポイントサーバーに接続されていません。コンフィグページで完全に無効にすることもできます。
-
Docket Cache のガベージコレクターとは何ですか ?
-
ガベージコレクターは 5 分ごとに実行されるスケジュールイベントで、キャッシュファイルの監視、期限切れエントリーのクリーンアップ、統計の収集を行います。
-
Docket Cache における RAM ディスクとは何ですか ?
-
RAM ディスクは、サーバーのメモリ (RAM) をストレージドライブとして使用するものです。ハードウェアデバイスの場合も、仮想ディスクの場合もあります。
RAM でのデータの読み書きは、SSD よりもはるかに高速です。Docket Cache のファイルを RAM ディスクに保存すると、パフォーマンスを大幅に向上できます。
RAM ディスクの作成にはサーバーの管理者権限 (root) が必要なため、共有ホスティングではこの方法を利用できないことにご注意ください。
以下は、RAM ディスクを作成して Docket Cache で使用するためのコマンド例です:
$ cd wp-content/ $ sudo mount -t tmpfs -o size=500m tmpfs ./cache/docket-cacheサーバーの起動時にキャッシュパスを自動的にマウントするには、
/etc/fstabファイルを更新してください。RAM ディスクの詳細については、以下を参照してください:
Windows では、RAM ディスクを作成し、DOCKET_CACHE_PATH が RAM ディスクのドライブを指すように設定してください。
-
WordPress のメモリ制限はデフォルトで 256 MB に設定されています。MySQL や Web サーバーと合わせると、256 MB を超えるメモリが必要です。ホスティングプランで提供されるメモリが合計 256 MB しかない場合は不十分であり、Docket Cache でサイトのパフォーマンスを向上させることはできません。
-
Docket Cache は他のオブジェクトキャッシュプラグインとどう違うのですか ?
-
Docket Cache はオブジェクトキャッシュアクセラレーターです。オブジェクトキャッシュを保存する前に、投稿クエリー、コメント数のカウント、WordPress の翻訳などを処理することで、キャッシュを最適化します。
-
他のキャッシュプラグインと併用できますか ?
-
併用できる場合とできない場合があります。ページキャッシュプラグインとは併用できますが、別のオブジェクトキャッシュプラグインとは併用できません。
-
LiteSpeed Cache と併用できますか ?
-
はい。LiteSpeed Cache プラグインには独自のオブジェクトキャッシュ機能があり、Docket Cache を無効にするよう求める通知が表示される場合があります。Docket Cache を使用するには、LiteSpeed Cache のオブジェクトキャッシュをオフにするだけです。
-
アクセスの多い WooCommerce ストアで Docket Cache を使用できますか ?
-
トラフィックの多い WooCommerce ストアにはおすすめしません。Docket Cache は Redis や Memcached のようなインメモリキャッシュに代わるファイルベースの選択肢として設計されており、アクセスの多いストアの負荷には対応しきれない場合があります。トラフィックの多い WooCommerce サイトでは、代わりに Redis を使用することをおすすめします。
-
VPS を使用しています。Redis の代わりに Docket Cache を使用できますか ?
-
使用できますが、VPS が Redis に対応している場合は、パフォーマンス向上のため Redis の使用をおすすめします。Docket Cache は、Redis や Memcached を利用できない環境に最適です。とはいえ、Docket Cache は VPS 上の小規模から中規模のサイトでも十分に機能し、ネットワーク接続が不要で、キャッシュキーが競合するおそれもありません。
評価
貢献者と開発者
変更履歴
26.04.12
- Added: DOCKET_CACHE_SKIP_UNCHANGED constant and “Skip Unchanged Cache Writes” option to turn it off.
- Fixed: Command::dropino_update() -> Wrong command in the WP-CLI help example.
- Fixed: View::parse_log_query() -> Cache View showed “Data Not available” for every cache file.
- Fixed: Cache Log -> Clicking a row selected a row further down in long logs, and nothing near the end.
- Fixed: Plugin::register_tweaks() -> WordPress Translation Caching looped until a fatal error with WPML String Translation.
- Fixed: Plugin::register_tweaks() -> WordPress Translation Caching gave text domains that were not loaded the translations of another domain.
- Fixed: Filesystem::opcache_compile() -> Cache files rewritten within the same second stayed stale when the host blocks opcache_invalidate() or the write came from WP-CLI.
- Improved: WP_Object_Cache::dc_save() -> Skip writing unchanged values to reduce OPcache wasted memory.
26.04.11
- 修正: Becache::export_transient() -> Transient が元の値ではなくシリアライズされた文字列として返されていた問題を修正しました。
- 修正: Becache::export_transient() -> Transient の値がタイムアウト値に置き換えられることがあり、期限切れの Transient がキャッシュされていた問題を修正しました。
- 修正: Becache::store_cache() -> エクスポートされた Transient が、常に最大 TTL を使用するのではなく、それぞれの有効期限を保持するようになりました。
- 修正: WP_Object_Cache::dc_update() -> incr/decr が新しい値を書き込む際に、保存されている型をリセットするようにしました。
- 改善: Becache -> 配列と stdClass の Transient をネイティブな PHP として保存し、その他のクラスは読み込み時にアンシリアライズするようにしました。
- 改善: WP_Object_Cache -> 26.04.10 で書き込まれた Transient キャッシュファイルを破棄するため、ディスク上のキャッシュ形式のバージョンを上げました。
26.04.10
- 修正: WP_Object_Cache::dc_get()/dc_save() -> シリアライズされたように見える値による PHP オブジェクトインジェクションを防ぐため、キャッシュされた文字列を保存されたとおりに返すようにしました。
- 修正: WP_Object_Cache::dc_get() -> キャッシュされた値を返す前に、保存されているキーとグループを検証するようにしました。
- 修正: CliOpcache -> WP-CLI OPcache の共有シークレットを、Web から読み取り可能なロックファイルではなく PHP ファイルに保存するようにしました。
- 修正: Plugin::flush_fcache() -> パストラバーサルを防ぐため、キャッシュファイルのインデックスを検証するようにしました。
- 修正: ReqAction -> 「オブジェクトキャッシュを一時停止」の状態変更を、nonce 検証済みのアクション内に移動しました。
- 修正: View::code_focus() -> DOM ベースの XSS を防ぐため、管理画面の通知をテキストノードで構築し、オプションキーを制限するようにしました。
- 修正: WpConfig::write_runtime() -> runtime.php には想定される on/off/整数の値のみを書き込むようにしました。
- 修正: Crawler -> Cookie はループバックリクエストにのみ付与し、リモートの Cronbot エンドポイントには付与しないようにしました。
- 修正: CronAgent::close_ping() -> キャプチャした Cron Hook の出力を Ping のレスポンスから除外するようにしました。
- 修正: EventList -> Cronbot テーブル内の Cron イベントの引数とコールバック名をエスケープするようにしました。
- 修正: Tweaks -> HTTP レスポンスは Authorization や Cookie を含まない GET リクエストの場合のみキャッシュし、Cookie を設定するレスポンスはキャッシュしないようにしました。
- 修正: MenuCache -> ログイン中のユーザーには共有メニューキャッシュを使用しないようにしました。
- 改善: WP_Object_Cache -> ディスク上のキャッシュ形式のバージョンにより、更新前のキャッシュファイルを読み込み時に移行するようになり、手動でキャッシュを削除する必要がなくなりました。
26.04.09
- 追加: Cronbot -> サービスの接続時にスポンサーに関する通知を表示するようにしました。
- 修正: nwdcx_cleanuptransient() -> データベースから Transient を削除する際に、プリペアドステートメントを使用するようにしました。
- 修正: Crawler -> リモートエンドポイントへのリクエストで SSL 証明書を検証するようにしました。
- 修正: ReqAction -> 管理画面の通知に表示される Cronbot のエラーメッセージをエスケープするようにしました。
- 削除: 重要バージョンのチェック -> 不要になりました。
26.04.08
- 修正: WP_Object_Cache::dc_log() -> ログに記録されるリクエスト URI のクエリー文字列の値をマスクするようにしました。
- 修正: Constans -> デフォルトのキャッシュログのファイル名を推測できないようにしました。
- 修正: Filesystem::log_remove_legacy() -> 旧名称のまま残っているキャッシュログファイルを削除するようにしました。
- 修正: CronAgent::close_ping() -> Ping リクエストが拒否された際に致命的エラーが発生する問題を修正しました。
- 修正: CronAgent::close_ping() -> 保存される Ping データから Cookie ヘッダーと Authorization ヘッダーを除外するようにしました。
26.04.07
- 修正: Polyfill PhpToken stub -> スコープ化された Nawawi\Symfony\Polyfill\Php80\PhpToken を継承するようにしました。
- 改善: PHP 8.4 との互換性のため、Symfony のベンダーライブラリを更新しました。
26.04.06
- 修正: admin/log.php -> 格納型 XSS を防ぐため、キャッシュログの出力に esc_textarea() を適用しました。
- 修正: Plugin::dc_log() -> ログに記録する前に REQUEST_URI の呼び出し元をサニタイズするようにしました。
- 修正: Plugin -> ‘init’ 時に認証なしでアクセスできた log/debug.log のダウンロードに権限チェックを追加しました。
26.04.05
- 修正: log.php で重複していた echo を削除しました。
26.04.04
- 追加: 「WP-CLI での OPcache の無効化」を切り替えるトグルをコンフィグ画面に追加しました (DOCKET_CACHE_WPCLI_OPCACHE 定数と同等)。
- 修正: CliOpcache::notify() -> GC 時やキャッシュファイルの個別削除時に HTTP リクエストが殺到するのを防ぐため、ファイルごとの通知をバッファーしてシャットダウン時に送信するようにしました。
- 修正: CliOpcache -> 高負荷時にワーカーが早期に終了した際の不要な 404 をなくすため、互換性チェックの前に REST ルートを登録するようにしました。
- 修正: CronAgent::receive_ping() -> 配列形式の値による PHP 8 の TypeError を防ぐため、Ping の入力値に型チェックを追加しました。
- 修正: CronAgent::receive_ping() -> CRONBOT が無効な場合は、close_ping() の後に明示的に return するようにしました。
- 修正: CronAgent::receive_ping() -> マルチサイトのループで try/catch によりサイトごとのエラーを分離し、Cronbot サーバーが継続的な障害を検知できるよう wpcron_error を報告するようにしました。
- 修正: CronAgent::run_wpcron() -> インスタンスフラグと try/finally による再入防止ガードを追加しました。
- 修正: CronAgent::run_wpcron() -> 例外発生時に ob_end_clean() を実行し、$run_event がゼロ未満にデクリメントされないようにしました。
- 修正: CronAgent::run_wpcron() -> PHP 8 の未定義変数の警告を防ぐため、$results と $cron_event を事前に初期化するようにしました。
- 修正: CronAgent::run_wpcron() -> URL エンコードによる回避を防ぐため、REQUEST_URI のチェックで urldecode() を使用し、先に wp_doing_cron() を確認するようにしました。
- 修正: CronAgent::send_action() -> 同じ IP からの on/off の呼び出しが衝突しないよう、キャッシュキーにアクションを含めるようにしました。
- 改善: CronAgent::send_action() -> 長時間実行されるプロセスで CDN のキャッシュが古くなるのを防ぐため、$stmp キャッシュバスターを 5 分ごとに更新するようにしました。
- 改善: CronAgent::check_connection() -> トラフィックの多いエンドポイントでの shutdown Hook のオーバーヘッドを減らすため、AJAX/REST/Cron リクエストではスキップするようにしました。
26.04.03
- 追加: CliOpcache — REST エンドポイント経由で、WP-CLI から Web サーバーの OPcache を無効化できるようにしました。
- 追加: CLI からの OPcache の無効化 (invalidation) のオン/オフを切り替える DOCKET_CACHE_WPCLI_OPCACHE 定数を追加しました。
- 追加: 設定のエクスポート/インポート機能を有効化/無効化する DOCKET_CACHE_CONFIGACTION 定数を追加しました。
- 追加: 設定のバックアップと復元のため、設定のエクスポート/インポート機能を追加しました。
- 修正: CliOpcache -> realpath() による検証でパストラバーサルを防止するようにしました。
- 修正: CliOpcache -> キャッシュの全削除時に過剰な HTTP リクエストが発生しないよう、一括削除時の通知を抑制するようにしました。
- 修正: CliOpcache -> REST ルートの登録時に共有シークレットを初期化するようにしました。
- 修正: ReqAction -> 「オブジェクトキャッシュの削除」で nginx の 502 エラーが発生する問題を、レスポンス後に削除処理を遅らせることで修正しました。
- 修正: Plugin::get_opcache_status() -> 共有ホスティングで他のサイトがカウントされないよう、ABSPATH でスクリプトを絞り込むようにしました。
- 修正: Plugin::get_opcache_status() -> キャッシュされたすべてのスクリプトに対して行っていた不要な is_file() による古さのチェックを削除しました。
- 修正: OPcache ビューアー -> XSS を防ぐため、設定値の出力をエスケープするようにしました。
- 改善: Filesystem::unlink() -> キャッシュファイルを個別に削除する際に、Web サーバーの OPcache に通知するようにしました。
- 改善: Filesystem::cachedir_flush() -> 内部の HTTP リクエストに Crawler クラスを使用するようにしました。
- 改善: Plugin::get_opcache_status() -> 概要ページではスクリプト配列の構築をスキップし、OPcacheView では上限を 50000 件にしました。
- 改善: Plugin::get_opcache_status() -> 共有ホスティングでのファイルキャッシュのスキャンにタイムアウト対策を追加しました。
- 改善: OPcacheView -> 「すべての項目」オプションを削除し、50000 件の上限に置き換えました。
- 改善: OPcacheView::get_status() -> ページの読み込みごとに二重にスキャンされないよう、結果をキャッシュするようにしました。
以前の変更については、changelog.txt を参照してください。
更新中にエラーが発生した場合は、wp-content/object-cache.php と wp-content/cache/docket-cache を手動で削除してください。よろしくお願いします。
