VPSの性能を比べたり、プラン変更の効果を確かめたりするには、CPU・メモリ・ディスク・ネットワークを分けて、同じ条件で繰り返し測ることが大切です。この記事では、sysbench・fio・iperf3 を使った測定手順と、数値がぶれる原因、測定結果をWordPressの体感速度と結び付けて読む方法を説明します。
測る前に決めておくこと
ベンチマークは「何を判断したいか」で測る項目が変わります。たとえば、PHPの処理が重いサイトならCPUのシングルスレッド性能、画像が多いサイトや大きなデータベースを持つサイトならディスクのランダムI/O、海外からのアクセスやバックアップ転送が多いならネットワーク帯域が判断材料になります。
測定の前に、次の点を決めておくと結果を比べやすくなります。
- 比べる対象: 事業者やプランの比較か、同じサーバーの設定変更前後の比較か
- 条件をそろえる: OS、カーネル、ツールのバージョン、テスト用ファイルのサイズ、スレッド数を記録して統一する
- 回数と時間帯: 1回の結果で判断せず、時間帯を変えて3回以上測り、中央値で比べる
VPSは物理サーバーを他の利用者と共有しているため、同じ仮想マシンでも時間帯によって数値が変わります。1回だけの測定で「このVPSは速い・遅い」と結論を出さないことが最初の注意点です。
また、高負荷のテストを長時間続けることは、事業者の利用規約で制限されている場合があります。規約を確認し、本番稼働中のサーバーではなく、測定用に立てたサーバーか、アクセスの少ない時間帯の検証環境で行ってください。
環境情報を記録する
まず、測定対象の環境を記録します。後から結果を見返したとき、条件が違うものを比べていないかを確かめるためです。
lscpu
nproc
free -h
df -h
uname -r
cat /etc/os-releaselscpu ではCPUのモデル名と仮想CPU数を確認します。同じプランでも、収容されるホストによってCPUの世代が異なることがあるため、比較の際はモデル名も控えておきます。
CPUとメモリを sysbench で測る
sysbench は多くのディストリビューションのパッケージで入れられます。
sudo apt install sysbench
# シングルスレッド
sysbench cpu --cpu-max-prime=20000 --threads=1 --time=30 run
# 仮想CPU数に合わせたマルチスレッド
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=30 run
# メモリ帯域
sysbench memory --memory-block-size=1M --memory-total-size=10G runCPUテストの結果では events per second を比べます。WordPressのPHP処理は1リクエストを1つのプロセスが処理するため、ページ生成の速さにはシングルスレッドの値が効きます。同時アクセスへの耐性を見たいときはマルチスレッドの値を見ます。
メモリテストでは転送速度（MiB/sec）を見ます。通常はディスクやCPUほど差が出にくい項目ですが、極端に低い場合はホスト側の混雑を疑う材料になります。
ディスクI/Oを fio で測る
ディスク性能は、WordPressではデータベースの読み書きやキャッシュファイルの生成に影響します。fio は細かく条件を指定できる定番ツールです。
sudo apt install fio
# 4KiBランダム読み込み（データベースに近い負荷）
fio --name=randread --filename=/var/tmp/fio.test --size=4G \
--direct=1 --rw=randread --bs=4k --ioengine=libaio \
--iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
# 4KiBランダム書き込み
fio --name=randwrite --filename=/var/tmp/fio.test --size=4G \
--direct=1 --rw=randwrite --bs=4k --ioengine=libaio \
--iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting
# 1MiBシーケンシャル書き込み（バックアップやファイル転送に近い負荷）
fio --name=seqwrite --filename=/var/tmp/fio.test --size=4G \
--direct=1 --rw=write --bs=1M --ioengine=libaio \
--iodepth=8 --numjobs=1 --runtime=60 --time_based --group_reporting
# 終わったらテスト用ファイルを消す
rm /var/tmp/fio.test設定の意味とつまずきやすい点は次のとおりです。
--direct=1はOSのページキャッシュを通さずに測る指定です。これを付けないと、メモリにキャッシュされた結果を測ってしまい、実際のディスクより大きな値が出ます。- テストファイルのサイズは、空き容量に余裕がある範囲で決めます。ディスクの残りが少ないサーバーで大きなファイルを作ると、サービスが止まる原因になります。
--filenameに/dev/vdaのようなデバイスそのものを指定すると、書き込みテストでデータが壊れます。指定先はテスト用のファイルにする、という点はこの記事の中で最も重要な注意です。
結果では、ランダムI/Oは IOPS と遅延（clat のパーセンタイル）、シーケンシャルは帯域（BW）を比べます。平均値だけでなく、99パーセンタイルの遅延が大きいと、ときどきページが遅くなる原因になります。
ネットワークを iperf3 で測る
ネットワーク帯域は、測定先によって結果が大きく変わります。自分で用意した別のサーバーとの間で測るのが、条件をそろえやすい方法です。
# 受信側（測定先サーバー）
sudo apt install iperf3
iperf3 -s
# 送信側（測定対象のVPS）
iperf3 -c 198.51.100.20 -t 30 -P 4
iperf3 -c 198.51.100.20 -t 30 -P 4 -R-P 4 は並列ストリーム数、-R は逆方向（受信側から送信）の測定です。上りと下りで帯域制限が違うプランもあるため、両方向を測ります。iperf3 の待ち受けポート（既定で5201番）は測定中だけ許可し、終わったらサーバーを止めてポートを閉じてください。
数値がぶれるときに確認すること
同じ測定で結果が大きく変わる場合は、次を確認します。
vmstat 1 10vmstat の st（steal）列は、ホスト側の他の仮想マシンにCPU時間を取られている割合です。ここが継続して高い場合、そのVPSの性能は自分の設定ではなくホストの混雑に左右されています。wa が高い場合はディスク待ちが発生しています。
ほかに、測定中にバックアップや cron ジョブが動いていないか、CPUの一時的な性能上限（バースト型のプランなど）がないかも確認します。バースト型のプランでは、最初の数分だけ高い数値が出て、その後に下がることがあります。
WordPressの体感速度と結び付ける
ハードウェアの数値が良くても、サイトが速いとは限りません。最後に、検証環境のWordPressに対して、実際のページ応答を測ります。
# 応答時間の内訳（1回分）
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s total: %{time_total}s\n" https://staging.example.com/
# 同時接続の負荷（検証環境に対してのみ実行）
ab -n 500 -c 20 https://staging.example.com/ab は Apache の付属ツール（Ubuntu では apache2-utils パッケージ）です。ページキャッシュが効いている状態と効いていない状態では結果が大きく違うため、どちらを測ったのかを記録します。他人のサイトや、許可のない本番サイトに負荷をかけるのはやめてください。
ハードウェアの結果とページ応答の結果を並べると、遅さの原因がCPU・ディスク・ネットワークのどこにあるのか、あるいはPHPやデータベースの設定にあるのかを切り分けやすくなります。なお、この記事のコマンドは各ツールの一般的な版のオプションを前提にしています（2026年10月現在）。版によって指定方法が異なることがあるため、手元の --help や man ページで確認してから使ってください。
まとめ
- 判断したい内容に合わせて、CPU・メモリ・ディスク・ネットワークを分けて測る
- 条件をそろえ、時間帯を変えて複数回測り、中央値で比べる
- fio は
--direct=1を付け、デバイスではなくテストファイルを指定する - 数値がぶれるときは
vmstatの steal と I/O 待ちを確認する - 最後はWordPressのページ応答を検証環境で測り、ハードウェアの数値と照らし合わせる