4

MySQL データストアを仮定すると、Ruby on Rails アプリで memcached を使用したくないのはいつですか?

4

4 に答える 4

10

アプリケーションがすべてのリクエストを迅速に処理できる場合は、memcached を使用しないでください。memcached を追加すると、アプリのコーディングに関して精神的なオーバーヘッドが増えるため、必要でない限り実行しないでください。

スケーリングの「あるうねり問題」。

于 2008-09-30T16:42:46.340 に答える
6

Memcache は強力な分散キャッシュですが、一部のコンテンツではローカル キャッシュよりも高速ではありません。キャッシュを使用すると、ボトルネック (通常はデータベース リクエストとネットワーク リクエスト) を回避できます。あまり頻繁に変更されない (あまり動的ではない) ため、ページ全体を HTML としてローカルにキャッシュできる場合、Web サーバーは memcache にクエリを実行するよりもはるかに高速にこれを提供できます。これは、ほとんどの memcached サーバーと同様に、memcache サーバーが別のマシンにある場合に特に当てはまります。

これの裏返しとして、いつか独自のサーバーに移動する必要があることがわかっているため、他のキャッシュ オプションの代わりに memcache をローカルで使用することがあります。

于 2008-09-30T17:56:33.057 に答える
4

memcached の主な利点は、分散キャッシュであることです。つまり、一度生成すれば、多くのサーバーにわたってキャッシュからサービスを提供できます (これが memcached が作成された理由です)。以前のすべての回答はこれを無視しているようです-非常にスケーラブルなアプリを構築する必要があったかどうか疑問に思います(これはまさに memcached の目的です)

Danga Interactive は、LiveJournal.com の速度を向上させるために memcached を開発しました。LiveJournal.com は、多数の Web サーバーと多数のデータベース サーバーを備えた 100 万人のユーザーに対して、1 日あたり 2,000 万以上の動的ページ ビューを既に実行していまし た。memcached により、データベースの負荷がほとんどゼロになり、ユーザーのページの読み込み時間が短縮され、リソースの使用率が向上し、memcache ミス時のデータベースへのアクセスが高速化されました。

(私の太字)

したがって、答えは、アプリケーションが単一のサーバーにのみ展開される可能性が高い場合です。

複数のサーバーを使用する可能性が高い場合 (スケーラビリティと冗長性のために)、memcached は (ほぼ) 常に良い考えです。

于 2009-04-01T22:39:32.703 に答える
0

期限切れになるものをきめ細かく制御したい場合。私のテストによると、memcachedのタイミング解像度は約1秒しかないようです。

例：1秒で期限切れになるように指示すると、1秒から2秒強の間留まる可能性があります。

于 2008-10-01T00:58:35.397 に答える