abの実行はそれぞれのサーバ上にて行っています。

今回は、apache,mysql,phpに関して、サーバ固有のチューニングは行わず、EC2で利用していた設定をServersManの方に適用して計測しました。

思ったよりServersManが頑張っていたので、とりあえずほっとしています。

WordPressのコンテンツ状況に多少の違いはありましたが、これほど差が出るとは思いませんでした。

Failed requestsに関して、EC2は382件あるのに対し、ServersManは0件でした。これは、処理能力の違いによりEC2の方では処理しきれなかったのかもしれません。

また、Transfer rateに関しても5倍以上の差をつけて、ServersManの方が速い結果となりました。その他の計測値についてもServersManの方が大差で勝っており、サーバの安定性、サポートの質などを考慮しなければ、EC2 micro instanceよりは、ServersMan@VPS Proの方がコストパフォーマンスは高そうです。

料金についても、ServersMan@VPS Proの方は、1980円に対し、EC2の方は$25程度かかっていたので、多少コストダウンしています。

EC2、ServersManの両サービスで、割り当てられるインスタンス、プランによって大元のサーバスペック、インフラも違う可能性があるので、同様の結果になるかは不明です。CPUなどは共有なので、この辺は、運の要素もあるかもしれません。

各、サーバでのabの結果は以下。

EC2 micro instance

$ ab -c10 -n1000 https://fukata.org/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking fukata.org (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.2.16
Server Hostname:        fukata.org
Server Port:            80

Document Path:          /
Document Length:        101894 bytes

Concurrency Level:      10
Time taken for tests:   2285.760 seconds
Complete requests:      1000
Failed requests:        382
   (Connect: 0, Receive: 0, Length: 382, Exceptions: 0)
Write errors:           0
Total transferred:      101632220 bytes
HTML transferred:       101168220 bytes
Requests per second:    0.44 [#/sec] (mean)
Time per request:       22857.601 [ms] (mean)
Time per request:       2285.760 [ms] (mean, across all concurrent requests)
Transfer rate:          43.42 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   12 130.0      1    1535
Processing:  1663 22823 31178.9   3880  137603
Waiting:       77 3259 9076.9    423   65292
Total:       1664 22835 31178.3   3881  137604

Percentage of the requests served within a certain time (ms)
  50%   3881
  66%  16392
  75%  34607
  80%  58282
  90%  67163
  95%  100522
  98%  111876
  99%  112836
 100%  137604 (longest request)

ServersMan@VPS Pro

$ ab -c10 -n1000 https://fukata.org/
This is ApacheBench, Version 2.3 < $Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking fukata.org (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        Apache/2.2.14
Server Hostname:        fukata.org
Server Port:            80

Document Path:          /
Document Length:        85413 bytes

Concurrency Level:      10
Time taken for tests:   297.972 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Total transferred:      85867000 bytes
HTML transferred:       85413000 bytes
Requests per second:    3.36 [#/sec] (mean)
Time per request:       2979.716 [ms] (mean)
Time per request:       297.972 [ms] (mean, across all concurrent requests)
Transfer rate:          281.42 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.8      0      24
Processing:  1055 2972 1139.9   2768   12319
Waiting:      149 1153 537.8   1090    8186
Total:       1055 2973 1139.9   2768   12319

Percentage of the requests served within a certain time (ms)
  50%   2768
  66%   3060
  75%   3269
  80%   3407
  90%   4084
  95%   5404
  98%   6218
  99%   6761
 100%  12319 (longest request)

月額料金が大体3000円程度かかっており、EC2 micro instanceだけで25ドル程度毎月請求があり、安定性などを抜きにしてマシンパワー的に25ドルも価値を見出せず、ずっと割高感を感じており、どうせならUbuntu対応もしたServersMan@VPS Proにまとめた方がお得なんじゃないか思い、今回新たにProを申し込みました。

前回は申し込んだ後に10分くらいでSSH接続できるようになったと思ったのですが、今回は10分以上経っても繋がらずSSHで繋げるようになったのはTwitterで@serversman_vps宛にDMを送った翌日に対応されたらしく繋がるようになりました。

Ubuntuだと安心していたのですが、ServersManの方で設定を色々いじくられていました。

rootユーザ

CentOSの頃は、開通時はrootユーザのみの提供だったのですが、通常Ubuntuだと直接rootユーザで操作するのではなく、sudoを使って一時的にroot権限を得て実行するというのが標準だと思いますが、Ubuntuの場合もrootユーザのみの提供でした。なので、以下のようにsudoで作業を行うユーザとsudoが実行できるように設定を追加しました。

作業用ユーザの追加

# adduser ubuntu
 ... Password等の設定 ...
# addgroup admin
# usermod -G ubuntu,admin ubuntu

sudoコマンドを実行できるように設定

# visudo

visudoの編集内容

#includedir /etc/sudoers.d

+ %admin ALL=(ALL) ALL

apache

Ubuntuを申し込むとシンプルセットという必要最低限のものしかインストールされていません。それでも、serversmanやapacheなど別に入れてもらわなくても良いものまで入っています。OSインストール後、SSHのみインストールしたものも提供してもらいたいです。

で、本題のapacheについてですが、Ubuntuでは、環境変数に実行ユーザなどを設定し、apache2.confなどでは、その値を利用するようになっていますが、ServersManの方でインストールされていたapacheには実行ユーザ等が直書きされていました。また、デフォルトのwww-dataではなく、daemonユーザになっていました。

普段、ローカルで利用しているUbuntuと設定が異なると後々面倒な事になると思ったので、ローカルにあるUbuntuサーバから設定ファイルのみをコピーすることにしました。手元にUbuntuサーバが無い人は、aptで設定ファイルごとpurgeして再度インストールする方法でも良いかもしれません。

cpuリソース割り当て

/proc/cpuinfoを見てみると、Standardの頃は2つだったCPUが4つに増えていました。また、メモリも1GB->2GB（保証は1GB）に増えているので、ブログ以外のメールサーバ等を一緒に動かしても、今のところは大丈夫なんじゃないかと思います。ベンチマークの結果等については、後日書きたいと思います。

まとめ

やっぱり、普段使い慣れたUbuntuだと比較的サーバ設定が楽でした。apt最高。

ただ、上記のapacheの件もあり、他にどの程度、デフォルトの設定と異なる部分が存在するのか調べていないので分かりませんが、環境を通常のUbuntuサーバの設定にリセットするシェルなどがあると助かる人が多いんじゃないかと思います。

気づくとサーバ構築して一度もyumの更新を行っていませんでした。

更新後、mysqlやapacheの諸々を再起動してみたところ、apacheの起動時に下記のようなapr_sockaddr_info_get() failedというのが表示されていました。

例：）

[root@dti-vps-srv1 ~]# /etc/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: httpd: apr_sockaddr_info_get() failed for dti-vps-srv1
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName

どうやら、127.0.0.1に対するdti-vps-srv1というホスト名が見当たらないということらしいので、/etc/hostsに下記のように追記する。

127.0.0.1 localhost.localdomain localhost dti-vps-srv1

• 利用可能な最大メモリが2倍に！！！
• IPv6の逆引き設定もOK
• inodeの上限設定、約3倍！

個人的に一番嬉しいのは何といってもメモリ容量の増量で、さっそく自分のStandardプランのサーバでも増えているか確認してみました。

$ free
             total       used       free     shared    buffers     cached
Mem:       1048576     340940     707636          0          0          0
-/+ buffers/cache:     340940     707636
Swap:            0          0          0

きちんと1GBになっていますね。ただ、今回増量した分のメモリは保証外ということらしく、サーバの負荷によっては変動するとのことです。

以下、引用になりますが、メール内容を転載します。

====================================================================
■　メモリ不足解消します！！！
====================================================================

ご利用中のお客様から頂いていたご要望の中でも多かった、メモリ不足
を解消するために、利用可能な最大メモリを2倍に引上げました。

これまでEntryプラン256MB、Standardプラン512MB、Proプラン1GBでご提供
していたメモリを、料金はこれまでと変わることなくEntryプラン512MB、
Standardプラン1GB、Proプラン2GBまでご利用いただくことができます！

Entryプラン　 256MB⇒　最大　512MB
Standardプラン 512MB⇒　最大　　1GB
Proプラン　　 1GB⇒　最大　　2GB

※保証メモリは従来通りですが、システムの空きに応じてご契約量の倍
までご利用いただけます。

====================================================================
■　IPv6の「逆引き設定」にも対応！！
====================================================================

8月10日にAレコード、AAAAレコード、IPv4のPTRレコード編集機能を追加い
たしまして、サービス開始時には想像を超える反響をいただきました！

そして本日より、
『PTRレコードの設定でIPv6の逆引きも可能になりました。』

IPv4の枯渇問題や、今後加速するIPv6への移行について、いち早く取り組
んでいたフリービットグループとして、スムーズな移行を支援するための
ための検証環境として機能についても整備が進めております！

====================================================================
■　有言実行！！inodeの上限設定を引き上げました！
====================================================================

前回、DTIから出しているプレスリリースをご覧になった方はご存知かもし
れませんが、予告しておりましたinodeの上限引き上げ、実装です！　

inodeの上限設定を今までの3倍に！

Maildir 形式を採用されている方々などファイルを多くご利用される方は、
ストレージを有効にご活用いただけます！

Entryプラン　　　 200,000⇒　 600,000
Standardプラン　　600,000⇒ 1,800,000
Proプラン　　　 1,000,000⇒ 3,000,000

メインで使用しているブラウザのChromeには既にWebsocketが実装されており、使用することが可能だということで、簡易的なチャットでも作ってみようかと思い、色々調べていました。

Jetty7でWebSocket開発：マピオンラボ(Java)

サーバ側の実装についてまとめられています。今回私が選択したのは、pywebsocketというものです。これは、apacheのモジュールとして提供されwsプロトコルの場合はwebsocketハンドラに処理を流すというものです。スタンドアロンで使用することもできるらしいのですが、今回はapacheのモジュールとして使用します。pywebsocketという名前からwebsocketハンドラはプログラム言語Pythonで実装する必要があります。

インストールした環境は、ServersMan@VPSでOSはCentOs 5.4です。それでは、早速手順の方を書いていきたいと思います。

手順は以下から

概要

ServersMan@VPS上にapacheのwebsocket

前提条件

• 環境はServersMan@VPSのEntryプランのものを使用する。
• yumにてhttpdをインストール済みとする。
• 下記の手順はユーザ「root」にて行うこと。
• ダウンロードなどの作業ディレクトリは「/root/tmp」とする。

作業手順

python-develのインストール

mod_pythonをコンパイルする際にPythonのソースが必要な為インストールする。

ダウンロード、インストール

# wget ftp://mirror.switch.ch/pool/3/mirror/centos/5.5/os/x86_64/CentOS/python-devel-2.4.3-27.el5.i386.rpm
# rpm -ivh python-devel-2.4.3-27.el5.i386.rpm

上記のダウンロードURLの接続が悪い場合などは、下記のサイトから他のミラーサイトのURLを使用する。
RPM Search CentOS 5 python-devel-2.4.3-27.el5.i386.rpm

mod_pythonのインストール

Issue 42 – pywebsocket – Python2.4 Support (CentOS/RHEL) – Project Hosting on Google Code

mod_python自体はyumでもインストールすることは可能だが、バージョンが3.2.xであり、pywebsocketはmod_pythonの3.3より低いバージョンはサポートしていない為ソースからコンパイルする。

ダウンロード、インストール

# wget https://ftp.kddilabs.jp/infosystems/apache/httpd/modpython/mod_python-3.3.1.tgz
# tar zxf mod_python-3.3.1.tgz
# cd mod_python-3.3.1
# ./configure –with-apxs=/usr/sbin/apxs –with-python=/usr/bin/python
# make
# make install

python.confの作成
ファイルパス：/etc/httpd/conf.d/python.conf
ファイル内容

LoadModule python_module modules/mod_python.so
AddHandler mod_python .py

pywebsocketのインストール

svnのtrunkを使用しても良いが、安定している可能性が高いバージョンが区切られたものを今回は使用する。今回使用したwebsocketの本家サイトをチェックし、バージョン0.5よりも新しいものがリリースされている場合は、できる限りそちらを使った方が良い。ただし、正常にインストールできるかは保証しない。

ダウンロード、インストール

# wget https://pywebsocket.googlecode.com/files/mod_pywebsocket-0.5.tar.gz
# tar zxf mod_pywebsocket-0.5.tar.gz
# cd pywebsocket-0.5/src
# python setup.py build
# python setup.py install

# python setup.py install

を実行した際にインストールされたディレクトリが出力されるのでメモを取る。今回は下記のディレクトリ。

/usr/lib/python2.4/site-packages/

python_mod_pywebsocket.confの作成
ファイルパス：/etc/httpd/conf.d/python_mod_pywebsocket.conf
ファイル内容

<IfModule python_module>
PythonPath “sys.path+[‘/usr/lib/python2.4/site-packages/’]”
PythonOption mod_pywebsocket.handler_root /var/www/html/wsh
PythonHeaderParserHandler mod_pywebsocket.headerparserhandler
</IfModule>

設定値の説明は下記の通り。

PythonPath “sys.path+[‘/usr/lib/python2.4/site-packages/’]”

pywebsocketがインストールされているディレクトリパス。

PythonOption mod_pywebsocket.handler_root /var/www/html/wsh

websocketハンドラを格納されているディレクトリ

pywebsocketの反映

インストールしたpywebsocketを反映させる為にapacheを再起動する。

# /etc/init.d/httpd restart

サンプルの配置・動作確認

上記でダウンロードしたpywebsocketにはサンプルが含まれているので、それが正常に動作するか動作確認を行う。

サンプルの配置

# cd pywebsocket-0.5/src/example
# cp echo_wsh.py /var/www/html/wsh/

動作確認

# python echo_client.py -s localhost -r /echo
Send: Hello
Recv: Hello
Send: 日本
Recv: 日本
Closing handshake
# python echo_client.py -s localhost -r /echo -m ‘hoge’,’foo’
Send: hoge
Recv: hoge
Send: foo
Recv: foo
Closing handshake

補足

websocketハンドラファイルの命名規則

PythonOption mod_pywebsocket.handler_root /var/www/html/wsh

上記で設定したmod_pywebsocket.handler_rootから下記のような命名規則でハンドラが実行されます。

[{ディレクトリパス}]{リソース名}_wsh.py

サンプル
アクセスURI：ws://localhost:80/echo
実行されるハンドラパス：/var/www/html/wsh/echo_wsh.py

アクセスURI：ws://localhost:80/chat/echo
実行されるハンドラパス：/var/www/html/wsh/chat/echo_wsh.py

以下、最近気になった出来事。

Google Wave Available for Everyone – Google Wave Blog

Googleが提供する超リアルタイムディスカッションツールであるGoogle Waveがついに一般公開されました。私は招待制の頃に使ったことがあるのですが、まだ、Chromeでしか利用したことがありませんがレスポンスがだいぶ良くなっています。以前は入力や画面スクロールにイライラしていましたが、今回はそれが解消されています。他人が現在入力している文字はもちろん、漢字変換などもリアルタイムに表示されるので、本当に話しているかのような感覚になります。また、APIなんかも公開されているので、これからさらに盛り上がっていきそうな感じです。

グーグルがVP8をOSS化、HTML5のvideo問題が決着か － ＠IT

さすが、Google！
他にも、Google TVやらiTunesキラーとますます目の離せないGoogleに注目です。

【レポート】Flashの父、「iPhoneは今後数年でFlashをサポートすることになる」 (1) Flashの歴史 | パソコン | マイコミジャーナル

個人的には、AppleのFlash排除に勢い付けてHTML5の普及し、Flash勢力は弱くなっていくと思うんですけどね・・・。Androidも現在はFlashをサポートしていますけど、それは現在のシェアが高いためでしょうし。Google自体がHTML5の普及に力を入れてることも考えると時代はFlash->HTML5になるんでしょうかね。

私個人としては、クローズドなFlashよりもオープンなHTML5側の人間です。

現在サーバ上で主にApache(WordPress, Munin)、MySQL、Postfix、Dovecot、Munin-Nodeを動かしているのですが、メモリが10MB以下になることが多く、さらに、Munin-Nodeのcron設定をしているプロセスから頻繁にOut of Memoryが発生してプロセスが落ちていたのでプラン変更でもしてメモリを増やそうかと思いました。

そこでふと気になった事があり、無料期間中にプラン変更を行っても無料期間も引き継がれるのだろうか。それともう一つ、Entryプラン->Standardプランに変更した場合、サーバ管理ツールが勝手にインストールされることはないだろうか。というものでした。気になったので早速メールにて問い合わせてみました。

すると下記のような返信が着ました。

【キャンペーンについて】

お客様の場合、無料対象期間が2010年6月30日までとなっております。
2010年6月までにプラン変更された場合には、最大3カ月無料は引き継がれ
ます。

●キャンペーン
https://dream.jp/vps/faq_01.html#a_15

【アプリケーションについて】

セットパッケージ（ディスクセットなど）につきましては、ご変更いた
だくことができかねますため、「ServersMan@VPS Entryプラン」のセット
パッケージを引き継ぐことになります。

サーバ管理ツール「BlueOnyx」はプラン変更によって自動的にはインス
トールされません。

Standardプランへのセットパッケージ「エンジニアセット」への変更が
必要となります。

現在はセットパッケージの変更を行うことができませんが、
5月末から6月初旬をめどにセットパッケージの変更が可能となる
予定でございます。

下位プランから上位プランへのプラン変更のみの場合、セットパッケージ
およびデータやアプリケーションのインストール状態はそのまま維持されます。

しかしセットパッケージの変更を行う場合には、サーバの初期化が必要となる
ため、アプリケーションのインストール状態やサーバ上のデータは維持する
ことができません。何卒、ご了承ください。

以下のページにて、ServersMan@VPSについてご案内させていただいて
おりますので、ご参照くださいますようお願いいたします。

●ServersMan@VPS　FAQ
https://dream.jp/vps/faq.html

とりあえず、現状を維持したままIPアドレスなど最小限の変更でプラン変更が出来ることが分かったので早速プラン変更を行おうかと思い、MyDTIにアクセスしてStandardプランを選択したのですが、次の画面にこんな表示が。

ご好評につき、1ヶ月以内のご提供予定となります。

で、さらに気になりました。この場合、プラン変更後VPS提供までの1ヶ月以内は現在のVPSは使用不可状態になるのか、それとも、プラン変更後VPSの提供と同じくらいに現在のVPSが使用不可になるのかということです。

これによって、当サイトがどれくらい停止するのかが変わってきます。前者であれば、1ヶ月以内当サイトは閲覧不可状態になります。それは非常にまずいので、またメールにて問い合わせてみました。

問合せ結果はこんな感じです。

下位プランから上位プランへプラン変更いただく場合、上位プランの
ご契約開始日までは下位プランにてご利用いただけます。

現在ご好評いただいておりますため、上位プランへのプラン変更をお申
し込み後、上位プランでのご利用開始までにお時間を頂戴いたしており
ます。

プラン変更をお申し込み後、ご利用可能となりましたら、個別にご案内
させていただきます。何卒、ご了承ください。

プラン変更後のVPSが利用開始になるまでは現在使用しているVPSが利用可能らしいので、早速申し込んでみたいと思います。ただ、プラン変更後のVPSが利用開始になるのは、無料期間が終了間際の6月下旬です。

また、今回チューニングを行ったのはWordPress自身ではなく、WordPressを実行するサーバ側です。行ったのは下記のチューニングです。

• PHPアクセラレータの導入
• MySQLのクエリキャッシュの導入
• Apacheの圧縮転送の導入

PHPアクセラレータの導入

PHPはインタープリタ言語と言われる、実行時に動的にコンパイルする言語です。そのため、実行毎にコンパイルするのではなく、コンパイル結果をキャッシュする為の役目をPHPアクセラレータが担ってくれます。

代表的なPHPアクセラレータにはGIGAZINEの下記の記事が詳しいです。

PHPアクセラレータで一番高速なのはどれか？ – GIGAZINE

今回ServerMan@VPSに導入したのは、APCというPHPアクセラレータです。インストールに関しては下記を参考にしました。

Installing PHP APC on GNU/Linux Centos 5 | 2bits.com, Inc. – Drupal Development, Customization and Consulting

Apacheの圧縮転送の導入

次に行ったのがApacheが配信するデータを圧縮するというもので、Apache1.3まではmod_gzipモジュールが、Apache2.0からはmod_deflateモジュールというのを使用して行います。
今回使用しているApacheは2.x系なので、mod_deflateを使います。

導入に関してはCentOSでyumでhttpd-develをインストールすると初期状態でmod_deflateが有効になっているので今回は割愛します。設定方法に関しては下記が参考になります。

mod_deflate を試してみた

ちなみに、mod_cacheとmod_deflateを併用して描画時間が短縮されるか確かめてみたのですが、同程度だった為、単体でより短縮されるmod_deflateを利用しました。ただ、mod_deflateは毎回配信するデータを圧縮するのでCPUに負荷がかかります。回線の使用帯域とCPUリソースを天秤にかけてmod_cacheもしくは、mod_deflateどちらかを使用するか決めると良いかと思います。

MySQLのクエリキャッシュの導入

MySQL :: MySQL 5.1 リファレンスマニュアル :: 4.13 MySQL クエリ キャッシュ

最後に行ったのがMySQLで発行されるSQLクエリをキャッシュするというもの。設定方法に関しては下記が参考になります。

クエリ結果のキャッシュ｜MySQL｜プログラムメモ

大きな設定に関しては上記の通りです。サーバ監視アプリのMuninをサーバにインストールしたので、これから定期的に計測して細かいチューニングを行います。また、改善されるようなチューニングが見つかった時には書きたいと思います。

今回のチューニングはあくまでもServerMan@VPSの限られたリソース内でのチューニングなので、サーバスペックが変わればチューニング方法も変わる可能性がありますので、各自のサーバスペックと相談の上チューニングを行ってください。また、今回はサーバ側の設定のみでWordPressには依存しないものなので、基本的なLAMP環境のチューニングとしても利用可能です。

最後に下記は上記のチューニング項目の現在の設定値になります。

PHPアクセラレータ(APC)

APC Support enabled
Version 3.0.19
MMAP Support Enabled
MMAP File Mask no value
Locking type pthread mutex Locks
Revision $Revision: 3.154.2.5 $
Build Date May 13 2010 14:20:28

Directive Local Value Master Value
apc.cache_by_default On On
apc.coredump_unmap Off Off
apc.enable_cli Off Off
apc.enabled On On
apc.file_update_protection 2 2
apc.filters no value no value
apc.gc_ttl 3600 3600
apc.include_once_override Off Off
apc.max_file_size 1M 1M
apc.mmap_file_mask no value no value
apc.num_files_hint 1000 1000
apc.report_autofilter Off Off
apc.shm_segments 1 1
apc.shm_size 30 30
apc.slam_defense 0 0
apc.stat On On
apc.stat_ctime Off Off
apc.ttl 0 0
apc.user_entries_hint 4096 4096
apc.user_ttl 0 0
apc.write_lock On On

MySQLクエリキャッシュ

| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 33554432 |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |

mod_deflate

SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary

両者の月額料金から言っておきます。ServerManは最低ランクのEntryプランだと490円(3ヶ月無料)。一方hetemlは1500円(15日間無料)です。

今回、Apache,PHP,MySQLのベンチマークテストに使ったソフトウェアは、PHPspeedというものです。WEBアプリ上でApache,PHP,MySQLのベンチマークテストを行えるということで、今回の要件にぴったりなソフトウェアです。

ベンチマークテストの比較の前にまずはサーバの基本スペックから紹介していきたいと思います。

System Info

heteml	ServerMan@VPS

PHP Info

heteml	ServerMan@VPS

MySQL Info

heteml	ServerMan@VPS

hetemlは共用サーバなので、自分の利用可能領域にどれだけのリソース（CPU,記憶容量,メモリ）が割り当てられているか分からないのに対して、ServerMan@VPSの方はそれらが割り当てられているのがしっかりと分かると思います。また、ServerMan@VPSの方は、Apache,PHP,MySQLとyumでインストールしただけの状態となっています。

それでは、実際にベンチマークの比較をしていきたいと思います。

ベンチマーク比較

heteml	ServerMan@VPS

パッと見MySQLのベンチマークの値に大きな開きが見えますね。hetemlはWEBサーバとDBサーバが別々になっているのも原因にあるのかもしれません。PHPの実行速度、書込・読込に関してはhetemlの方が勝っているようです。hetemlは共用サーバなのでタイミングによってはCPUリソースの多くを使えるのかもしれません。各テストの内容については下記にまとめました。

それで、これらの値が実際のWEBアプリのレスポンスとどの程度関係してくるのか、次に、WordPressの表示時間について見ていきます。

各テスト内容

WordPressのベンチマーク

WordPressの基本情報

クエリ数と表示時間

yumで構築しただけのデフォルトの設定にも関わらず、ServerMan@VPSの方が倍以上速い上に安定していますね。APCなどのPHPアクセラレータやMySQLのチューニングを行えばさらに速くなるでしょう。それに比べてhetemlはDB回りのベンチマークが関係しているのか遅くなっている上にかなり時間にばらつきがあり不安定です。これは、hetemlが共用サーバなため、同じサーバに載っている他のユーザのプロセスがサーバリソースを使用してしまうことで、自分のプロセスが圧迫されてしまうのが原因かと思われます。ですので、この結果がばらつきのある中でのどの程度のランクの結果なのかはもう少し定期的に計測する必要があります。

今回のベンチマークテストの比較によって、ServerMan@VPSが値段の割に安定していることや、逆に、hetemlが予想以上にばらつきがあったことなどが分かりました。正直、ServerMan@VPSは500円でこのスペックなら申し分ないです。無料期間が3ヶ月もあるので、まだ申し込んでない方は是非ご自身で確かめてみて下さい。

hetemlとの契約終了が2010/11/30なのですが、近いうちにServerMan@VPSに引っ越そうかと考えています。

下記は、各テストの5回分の計測結果です。

Synthetic PHP BenchMark

heteml	ServerMan@VPS

Synthetic MySQL BenchMark

heteml	ServerMan@VPS

Synthetic Read/Write BenchMark

heteml	ServerMan@VPS

Real World PHP BenchMark

heteml	ServerMan@VPS

Real World PHP & MySQL BenchMark

heteml	ServerMan@VPS

Server Benchmark

heteml	ServerMan@VPS