基本的にキャッシュに頼った高速化はキャッシュミスが発生したときのペナルティーがあるので、なるべくボトルネックになる部分を特定して、それを解消するべきだと思っています。

例えばHDDをSSDに完走しての高速化とか、十分なメモリを積んで仮想記憶に頼らない運用とか。ソフトウェアに関しては時間のかかる処理はさせない、どうしても外せない時間のかかる処理は計算できるものはあらかじめ計算してオンデマンドでの処理を減らすなど。(これにはデーターベースのインデックスの整備も含まれます)
CPUを増やしての高速化は費用対効果考えると割と後回しにしたい高速化技法ですね。でも、GPGPUやFPGAで割と単純だけ処理するデータ量が莫大なものを処理する方法はいいと思っています。
実際にはコスト対効果を狙って、良く使うデータだけバイト単価の高い高速記憶装置(キャッシュメモリー)に置いて高速化。

APCを選択したのは、xhprofというPHPのプロファイラーで一番時間かかっているのが、日本語化処理だったので。(次に遅かったのがmysql部分。)

さて、今回sakuraインターネットのVPSでやたらwordpress(BuddyPress,bbPress付き)が遅くてどうしようもなかったのでいろいろ調べてみました。
まず、topコマンド。CPUタイムは10%も消費していません。disk I/Oが問題なんだろうと当たりをつけてswapoffコマンド。仮想記憶を停止します。これはメモリ消費が1GB中40%程度だったのでそうしました。
次にSSDのサーバーに載せ替えてもらえないかと打診したら予算の都合で却下。

まあ、ある意味に予定調和。(苦笑)

ちなみに、
# dd if=/dev/zero of=aaa.bin bs=1024 count=1024000
1048576000 bytes (1.0 GB) copied, 10.5271 s, 99.6 MB/s
# dd if=aaa.bin of=/dev/null
1048576000 bytes (1.0 GB) copied, 98.8714 s, 10.6 MB/s
disk readがお話にならないくらい遅い。通常のデスクトップPCで80MB/sくらいです。

この状況だとdisk readを最小に抑える工夫が効果ありそうですね。
wordpressのDB構造、インデックス(計算できるところは先に計算しおくタイプの効率化)が全然やっていないので(まあ、プラグイン都合で変わるのでwordpress本体ではどうにも出来ないし、プラグイン側でDB構造にちょっかいだすわけにもいかないんでしょうね。)しかたない部分はあります。
そんなわけで、PHPにAPCを入れました。共有メモリにある程度一度計算した内容をバッファリングしてくれます。
これで一発目は仕方ないにせよ、二回目以降はまあまあ実用的な速度で動いてくれるようになりました。とっても不本意。

APCを選択したのはxhprofというPHPのプロファイラーで時間がかかっているのが日本語化しょり、ついでmysqlのアクセスと特定できたから。

DBのインデックスの見直しは時間ができたらやることにして、当面はコンテンツの流し込みですねー。