WPMSでのパフォーマンス
私のWPMSサイトは8コア/ 32mb RAMサーバーでホストされていますが、応答時間は非常に長いです。私たちは1マウントあたり約1000のブログ（単一のdbに35,000以上のテーブル）と70,000のページビューを持っています。ページビューの多いブログを別のDBに移動したり、ハイパーdbプラグインを使用してすべてのブログをdbごとに100のブログに分割したりすることで、応答時間を短縮できると思います。どう思いますか？
はい、あなたはデータベースを分割する必要がある時点をはるかに超えています。 ;）
あなたのハードウェアを考えると、1日当たり70kページビューはかなり簡単なようです。たとえその大部分が1日あたり10時間の時間枠で広がっていても、あなたは（大体）1秒あたりに提供されるページを扱っています。あなたのハードウェアはちょっとした問題なしにそれに対処するべきです。 （それからまた、それはWPです...）
Imo、サイトを複数のデータベースに分割する前に、memcachedとobject-cacheをインストールしてください。そうすることで、DBクエリの数が減ります。
次に、必要に応じてBatCacheまたはSemiologic Cache（独自のオブジェクトキャッシュ実装がある）を追加します。これは、memcachedベースのキャッシュ（ゲストに提供される最初のキャッシュページとゲストに提供される2番目のキャッシュページ） ）あなたが最終的に単一のサーバーを超えて成長すると思うなら、あなたは静的なファイルベースのキャッシングを望んでいません。あなたがそうしないと思うならば、Total CacheあるいはSuper Cacheさえも良い選択です。
最後に重要なことを言い忘れましたが、mod_deflate（Sem Cacheにも組み込まれています）とアセットの連結（やはりSem CacheやTotal Cacheなどによって行われます）を設定しましたか？これにより、認識されるロード時間が大幅に短縮されます。
編集：すみません、私は質問をもう一度読み、あなたは一日あたりではなく、毎月70Kを言う。これは、サーバーの負荷としてはさらにばかげています。1分あたり2ページのサービス、つまり、CPUはほぼ常にアイドル状態になっているはずです。
まずdb-cacheを試してください。クエリがcache-dになり始めた場合は、5〜6倍の改善が見られます。 Wordpressは恒久的なキャッシュを持っていません。誰かが言うことができる、なぜですか？すべてのメタデータ、ユーザーデータは、ページが読み込まれるたびにデータベースから取得されます。ナンセンス...