WordPressは、php , Apache ,  MysqlDB　の3つを揃えないと走らないので、いわゆる、LAMP若しくは、XAMPが必須条件となるので、この内のどれか1つの性能にウイークポイントがある場合、最速とはならない。Microsoft Windows環境では、お手軽に、XAMPPを導入すればよく、Linux環境では、必要に応じてLAMPP(Linux_Apache_MySQLd_PHP_Perl)をインストールすれば良いのだが、現在、最も高速に動作させようとするなら、適度なCPUリソースと、nginxフロントエンドを採用するのが良い方法である。各々のバージョンに関しては、賛否両論があるものの、概ね以下のような構成とすれば間違いがない。

• L : Linux CentOS 6以上
• A : Apache Apache 2.x.x
• M : MySQLd Version 5.5.x
• P : PHP 7.0.x 以上　+ OPCache + APCu構成
• P : Perl これは適宜で良い

まず、この構成ならば、遅くて困るということはないと考えられる。
MySQLdに関しては、CentOS7 系ではMariaDBが標準となっているが、MySQLd 5.5.xとの速度差はそれほど大きくなく、MySQLd 5.6.xは最新機能を有する割には、5.5.ｘよりも低速なので、無理をして、MySQL 5.6.ｘ系へバージョンアップする必要はない。

残るところ、CPUの性能にしたがって、速度が向上していくが、経験値的には、概ね17Page / sec.あたりを限界として、これ以上の高速化を考えるのであれば、CPUの性能向上よりも、nginxを導入したほうが、コスト面では有利である。一般的には、CPUの性能は、Core 2 Duoの E8500か、E8600あたりの性能が出ていて、CPUのCacheが4MB以上のものが望ましく、メモリーアクセスの観点からは、CPUのクロックは、3.0GHz周辺が望ましい。ただし、マイクロアーキテクチャの性能が向上しているので、Xeonのプロセスルールが、14nm以下のCPUでは、概ね2.0GHｚ以上であれば、高速化には、ほぼ問題が無くなる。

これらは、経験則でしか無いが、ここらへんの目安で、RAMが、512MB以上のVPSを選べばそこそこ爆速になる。
VPS系やレンタルサーバー系では、この他に、ディスクIOが、そこそこ出ていないと、WordPressは大幅に減速するので、出来ることなら、HDD RAID-10か、SSDを採用しているサーバーを選んだほうが、CPUの性能に拘るよりも、利点が大きいことがわかった。

そのような意味で、リソースが保障されている完全仮想化VPS上で、SSDを採用したサーバーを選んでおけば、実質的には、問題なく爆速なWordPressを体験できるというわけである。

どこのサーバーが良いかは、使ってみないと判らないが、CPUのクロックやメモリー構成が、そこそこなのに、速度が出ない場合には、大体の場合、ディスクIOに問題を抱えている場合が多いので、できるでけ空いているサーバーや、SSD採用のサーバーへ引っ越してしまったほうが、手っ取り早い。

BudgetVMを使い始めて、少し経つのだが、現在のロケーションは、Dallasにある。
もちろん、日本からのアクセスでは、それなりに遅延があるので、そこそこのスピードしか出ないのだが、ネットワーク遅延以外にも、Apache+MySQL+WordPressという比較的重い処理では、最適化が重要である。

Tokyoからのネットワーク遅延

# ping -c 5 px1.xaffy.net
PING px1.xaffy.net (192.157.245.52) 56(84) bytes of data.
64 bytes from 52.245-157-192.rdns.scalabledns.com (192.157.245.52): icmp_seq=1 ttl=51 time=144 ms
64 bytes from 52.245-157-192.rdns.scalabledns.com (192.157.245.52): icmp_seq=2 ttl=51 time=144 ms
64 bytes from 52.245-157-192.rdns.scalabledns.com (192.157.245.52): icmp_seq=3 ttl=51 time=146 ms
64 bytes from 52.245-157-192.rdns.scalabledns.com (192.157.245.52): icmp_seq=4 ttl=51 time=144 ms
64 bytes from 52.245-157-192.rdns.scalabledns.com (192.157.245.52): icmp_seq=5 ttl=51 time=148 ms

--- px1.xaffy.net ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4370ms
rtt min/avg/max/mdev = 144.931/145.856/148.298/1.370 ms

この値は、Tokyo –> Dallas:145.8(ms),Tokyo –> Los Angeles:114.2(ms)と日本から比較的近いLos Angelesでも、8,800km前後離れているので、良くして、せいぜいのところが、100(ms)前後である。
しかし、最近当確を現してきた海外のKVM仮想化などのサーバーを借りてみると、たとえ、114(ms)前後のネットワーク遅延でも、そこそこのレスポンスが得られるので、リクエストあたりのクエリーが多いWordPressなどの応答には、リクエストあたりの遅延は、クエリー数それぞれがネットワーク遅延の影響を受けるので、トータル的に見ると、ばかにならない大きさの遅延に拡大してしまう。

CPUのパワーやメモリー搭載量にもよるが、phpのバージョンを上げ、phpモジュールベースのCacheを使ったり、MySQLのクエリーCacheを使うと、良くすれば、遅延の解消が期待できる。
これに関しては、距離が近いところよりも、遠いところでのCacheに対する効果は大きく、如何に速く、リクエストを完結できるかによって、ブラウジング性能には大きな差が付く。

これまで、ネットワーク遅延が、145(ms)ならば、ある程度仕方ないと考えて来たのだが、これまでの、php5.5.x系から、php5.6.x系や、php7.0.x系へ移行すると、大幅なパフォーマンスの向上が期待できるため、少し諦めていたWordPressをもう一度確かめてみることにした。

結果はご覧の通り、見事なまでの変貌ぶりを示してくれているわけである。
OPCacheの性能を期待する場合には、できるだけオンメモリ－で動作させ、無用なディスクIOが発生しないように工夫することで、アクセススピードの向上が出来る。

又、並列的にWordPress上のCacheを有効にするのも効果がある場合もあるが、大抵の場合、HDDアクセスの遅延も、忘れてはならない遅延なので、SSDを採用しているようなサーバーでは効果があっても、HDDベースのサーバーでは必ずしも良好な結果とならないので、この際、WordPressのCacheは使わないほうが良いと判断した。

当面のところ、これでしばらく運用してみる予定である。

旧来の導入記事は、他所にさっさと移してしまったので、当面はそちらとの比較が出来ると思う。
リンク先：http://px24.xaffy.net/