0

最近、トラフィックの多い PHP サイト用に memcached をセットアップしました。以前は APC を使用していましたが、これには独自のキャッシュ システムを持つ可能性がありません (1 つのサーバーで 1 つのキーを無効にしても、他のサーバーでは無効になりません)。

memcached が http サーバーと同じマシン上にあるか、別のサーバー上にあるかという大きな違いに気付きました。

同じサーバー上の http+memcached -> 0.06 ページの配信に費やされた平均時間

http と memcache 差分サーバー (ただし NAT の下) -> 0.15 - 0.20 ページを配信する

したがって、これは大きな違いであり、キャッシュ システムを http と同じマシンに配置する方がよいのではないかと考えています。追加の複雑さは、Web サイトが (ロード バランサーを介して) カップルの http サーバーによって提供されているという事実です。したがって、実際にはレプリケーションを備えたキャッシュシステムが必要です。各httpサーバーにはキャッシュの「コピー」があり、変更を「マスター」にのみ書き込みます(または同様のことを行う他のアプローチ)。

そのようなシステムがいくつかあります (couchbase、redis、aso)。ローカルキャッシュサーバーではなく「ゲート」への接続を許可しないため、couchbaseはこれには適していないと思います。Redis が動作する可能性があります。他についてはまだ確認中です。

主なことは、ウェブサイトを高速化するために誰かがこのアプローチを試したことがありますか? 各マシンにキャッシュの「コピー」を持たせることによって (他のマシンとの同期を維持する) ?

4

1 に答える 1

5

メモリデータグリッドに分散されているGigaSpacesXAPソリューションを使用できますが、jettyと統合されているため、Webアプリを展開して単一の管理システムから管理できます。中央分散データグリッド（単純なキャッシュとして使用できます）は、メインキャッシュとの同期を維持する各Webコンテナーにローカルキャッシュを持つことができます。そのために桟橋統合を使用する必要はありません。独自のWebコンテナを使用し、コードを介してローカルキャッシュが埋め込まれた分散キャッシュへのプロキシを作成するだけです。または、メインの分散キャッシュがなくても、Webコンテナ間で完全に複製されたトポロジを使用できます。各Webコンテナには、Webコンテナの他のインスタンスと同期するキャッシュ全体の完全なコピーが含まれます。

あなたはでもっと読むことができます：

http://wiki.gigaspaces.com/wiki/display/SBP/Web+Service+PU http://wiki.gigaspaces.com/wiki/display/XAP9/Web+Jetty+Processing+Unit+Container http：// wiki.gigaspaces.com/wiki/display/XAP9/Client+Side+Caching

免責事項：私はGigaSpacesで働いている開発者です。

于 2012-09-27T12:37:13.067 に答える