WordPressオブジェクトキャッシング:Redis、Memcached、ネイティブAPI

公開: 2017-11-04

自由に拡張できるエンタープライズグレードのWordPressサイトには、ページや画像を超えた永続的なキャッシュメカニズム、実際のP​​HPオブジェクトをキャッシュできるメカニズムが必要です。 WordPressはWordPressObjectCacheを介してオブジェクトキャッシュメカニズムを提供しますが、優れたレバレッジとパワーを提供する他のソリューションがあります。 しかし、そのすべてに入る前に、まず、オブジェクトキャッシングとは何か、そしてそれがPHPでどのように機能するかを確認する必要があります。

オブジェクトキャッシングとは何ですか?

PHPはオブジェクト指向言語です。 オブジェクトパラダイムを使用してコードを構造化します。 その結果、WordPressサイトは、(メモリマネージャーによって)絶えず作成、インスタンス化、破棄されるさまざまなPHPオブジェクトで構成されています。 オブジェクトの作成と破棄には、特にオブジェクトが多い場合、コストのオーバーヘッドがあります。 ただし、これらのほとんどはコア機能を表すため、頻繁に再利用される傾向があります。 これは、アプリケーションがそれらを再度必要とするたびに、最初からそれらをインスタンス化する必要があることを意味します。

頻繁に使用されるインスタンス化されたオブジェクトをキャッシュして、常に破棄して作成する必要がない場合はどうでしょうか。

PHPのserialise()関数を使用して、オブジェクトまたはプリミティブを、後でアクセスするためにメモリまたはディスクに格納できる数値表現(バイトブロブ)に変換できます。 次に、 hash()関数を使用してバイトブロブのハッシュ数を計算し、両方を格納します。 キーとしてのハッシュと値としてのバイトブロブ。 それを取得するには、最初にキーとして格納されたバイトブロブの計算されたハッシュ番号を使用します。 この方法で、あらゆるもの(文字列、整数、オブジェクト、ブール値、配列など)を保存可能な値の表現に変換できます。

例:

$serialized = serialize( array ( 'test' ));

unserialize()を使用して、逆の操作を実行します。

$original = unserialize ( $serialized );

一般に、オブジェクトをキャッシュする方法は3つあります。ネイティブのWordPress Object Cache、Transients API、またはRedisやMemcachedなどの外部Key-Valueストアを使用する方法です。

WordPressオブジェクトのキャッシュ

WordPressは、ネイティブのWordPressObjectCacheとTransientsAPIの2つのオブジェクトキャッシングAPIを提供します。 それらは同一であり、これは混乱を引き起こす可能性がありますが、その背後には論理があります。

ネイティブのWordPressObjectCacheは、オブジェクトとプリミティブをキャッシュに保存できますが、デフォルトでは永続的な方法では保存できません。 これは、キャッシュがメモリ内で発生し、キャッシュされたオブジェクトがリクエストのライフタイムサイクルを超えて存続しないことを意味します。 そのため、異なるページの読み込み間でキャッシュされたオブジェクトを共有することはできません。 ドロップインを使用して独自のストア実装を提供する必要があります。ドロップインは、WordPress機能を拡張できる「高度な」プラグインです。 それらは、WordPressダッシュボードのプラグインリストで確認できます。

WordPressドロップイン

一方、Transients APIは、そのまま使用できます。 変数、配列、有効期限に関連付けられたオブジェクトをデータベースに直接保存し、永続的なオブジェクトキャッシュを設定できます。 ただし、問題は、キャッシュされたオブジェクトの有効期限が切れても、データベースに残り、スペースを占有することです。 これは、データベースの保守に余分なオーバーヘッドが費やされ、期限切れのオブジェクトがときどきプルーニングされることを意味します。

WordPressは、独自の永続オブジェクトキャッシュを実装したかどうかを検出し、その場合、Transients APIへの呼び出しはバイパスされ、WordPressオブジェクトキャッシュにルーティングされます(したがって、それらが同一である理由)。

開発者は、独自のオブジェクトキャッシュを実装するか、WordPressプラグイン(後で詳しく説明します)を使用するか、Pressidiumクライアントの場合は独自の実装を使用できます。 間違った状況で使用するとパフォーマンスが低下する可能性があるため、デフォルトではオブジェクトキャッシュをオンにしていません。 WordPressサイトでのオブジェクトキャッシングに関しては、「万能」ソリューションはありません。

RedisとMemcached

Key-Valueストアは、テーブルや事前定義されたデータ型を使用して、RDBMSなどのレコードに情報を格納しません。 これらは、プログラミング言語で見られる辞書データ構造のように、キーと値のペアを格納および取得するように設計されています。

そのようなストアの良い例の1つがRedisです。 辞書データ構造の他に、範囲クエリを使用した並べ替えられたセットや半径クエリを使用した地理空間インデックスなどの高度なものを含む、その他の多数をサポートします。 永続的なオブジェクトキャッシュを提供します。

Redis

Redisは単なるKey-Valueストアやキャッシュではありません。 クラスター構成でのデータレプリケーション、スクリプティング、高可用性をサポートします。 必要なディスク上の永続性のレベルを微調整することもできます。 Redisの良いところは、再起動してもほとんどのキャッシュがディスク上にあり、失われるデータはごく一部にすぎないことです。 重要なのは、再起動時にサーバーがキャッシュを再構築する必要があり、これによりほとんどの場合負荷が増加するということです。 Redisでは、これは起こりません。 さらに、期限切れのオブジェクトはデータベースからすぐに削除されます。 そこにも管理オーバーヘッド時間はありません。

Redis Labsには、エンタープライズでのRedisのユースケースを紹介する優れたページがあります。これらは、非常に大規模なデータセットから、全文検索、リアルタイムシリーズ、Spark統合などにまで及びます。

これらの機能はすべて複雑で、場合によっては速度が犠牲になりますが、Redisドロップインコードを最適化すると、かなりのメリットが得られます。 Redisが永続的なオブジェクトキャッシングを実行するという事実を忘れないでください。これはMemcachedが実行しないことですが、使用するのははるかに簡単です。

Memcached

Memcachedは、公式Webサイトに準拠した、メモリ内の高性能オブジェクトキャッシングシステムであり、動的Webアプリケーションを高速化し、データベースの負荷を軽減するように特別に設計されています。 また、Redisよりもはるかに簡単で簡単に使用できます。

Webページのオブジェクトキャッシングを実行するように特別に設計されているため、またインメモリデータベースを使用しているため、オブジェクトキャッシングソリューションとしては最速です。 ただし、前述したように、サーバーが再起動すると、キャッシュがなくなります。 そして、それが再構築されるまで、おそらく負荷が増加するでしょう。 しかし、作成者が言うように、「それをあなたのウェブサイトの短期記憶として考えてください」、それでそれはむしろあなたが最初に何をしたいかに依存します。

Memcachedはインメモリデータベースを使用してキャッシュを保持するため、SQLクエリや関数呼び出しの出力などをキャッシュするのに非常に効率的です。

WordPressプラグイン

  • WP Redis、公式のRedisWordPressプラグイン。 WP-CLI、クラスタリング、およびレプリケーションをサポートします。
  • RedisオブジェクトキャッシュWordPress用のもう1つのバックエンドRedisプラグイン。
  • Memcachedオブジェクトキャッシュ、Memcachedのバックエンド。
  • 期限切れのトランジェントを削除します。このプラグインは、期限切れのトランジェントオブジェクトをデータベースから削除します。 マルチサイトにも対応!

ベンチマークの実行方法

私たちの記事のポイントは、オブジェクトのキャッシュに興奮し、自分でいじり始めることです。 さまざまな永続キャッシュの実装を試して、アプリケーションの動作を確認できます。 PHPのmicrosecond()関数を使用して、呼び出しのベンチマークを行うことができます。 例: wp_cache_get()を呼び出す前後にmicrosecond( microsecond()を呼び出し、値を減算して結果を保存します。 さまざまなキャッシュ実装に対してこれを実行し、どのような場合にパフォーマンスの向上に気付くかを確認します。

Pressidiumでは、デフォルトでオブジェクトキャッシュを有効にしていません。これはリクエストできるものですが、通常、最初からそれを優先することはお勧めしません。 テストを実行し、サイトがそのメリットを享受できることを確認します。

結論

ページをレンダリングするために、アプリケーションが2,000個の一時オブジェクトを読み取る必要があるとします。 これは、データベースで2,000回の読み取りを意味します。 永続オブジェクトキャッシングシステムを使用することにより、これらの2,000回の読み取りがKey-Valueストアにオフロードされます。 memcachedを使用すると、突然の再起動ですべてのキャッシュが失われるリスクがあります。 一般に、RedisはMemcachedほど高速ではないかもしれませんが、そのエンタープライズ機能と永続性は長期的にはメリットがあります。

ただし、1つのサイズですべてに対応できるわけではありません。 たとえば、実際にWebサイトの速度を低下させたRedisインスタンスや、Webサイトを大幅に高速化した他のケースを確認しました。 これは、アプリケーションが使用する多数のオブジェクトと関係があります。一般に、アプリケーションが少数(たとえば、ダース)を使用する場合、オブジェクトキャッシュのメリットはあまり得られず、最悪の場合、次のようになります。ネットワークオーバーヘッドがあります。 ただし、アプリケーションが数百に及ぶ場合は、一見の価値があります。