高トラフィックのウェブサイトでは、サービスの特別な設定が必要です。選択したサービスに応じて、VPSサーバーの高性能を達成するための推奨事項があります。

単にリソースを増やすだけでは、VPSサーバーの高性能を実現することはできません。サービスの設定も必要です。

デフォルトでは、サービスは低～中程度のトラフィックを持つ典型的なプロジェクトに適した基本設定になっています。

明確にするために、トラフィックの基準を定義します：

• ウェブサイトの低トラフィック：月間10,000訪問以下（1日約300回、5分ごとに1回の訪問）。
• ウェブサイトの中程度のトラフィック：月間10,000～90,000訪問—平均50,000回/月（1日約1,600回、1分ごとに1回の訪問）。
• ウェブサイトの高トラフィック：月間100,000訪問以上、つまり1分あたり2回以上の訪問。

nginxをプロキシウェブサーバーとして、php-fpm（この場合はphp8.3-fpm）を主要なハンドラーとして使用する構成を分析します。

私たちが使用したのは、Linux Debian 12を実行するVPSサーバーで、6つのCPUコア、8GBのRAM、50GBのSSDを備えています。

特にphp8.3-fpmに対してパフォーマンスを最適化します。デフォルト設定でリンク分析スクリプトを実行したところ、数分でリクエストレートが秒間9リクエストから5リクエストに低下しました。さらに5分後、パフォーマンスは秒間1.5リクエストに低下し、サービスが詰まり始め、すぐにBad Gatewayエラーを返しました。

その間、サーバーの負荷は大幅に増加せず、リクエストを処理するのに十分なリソースがまだ残っていました。

1. 新しいphp-fpm設定ファイル

/etc/php/8.3/fpm/pool.d/domain.conf に新しい設定ファイルを作成します。

古いファイルは www.conf.bak に名前を変更します。これにより使用されなくなりますが、必要に応じて .bak 接尾辞を削除して復元できます。

2. 設定の詳細

[www]
user = www-data
group = www-data
listen = 127.0.0.1:9000
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

; Process manager
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 500
pm.max_spawn_rate = 32
pm.process_idle_timeout = 10s

; Connection settings
listen.backlog = 65535
listen.allowed_clients = 127.0.0.1

; Timeouts
request_terminate_timeout = 30s
request_slowlog_timeout = 5s
slowlog = /var/log/php8.3-fpm/slow.log

; Status monitoring
pm.status_path = /fpm-status
ping.path = /ping
ping.response = pong

; Logging
access.log = /var/log/php8.3-fpm/access.log
access.format = "%R - %u %t \"%m %r%Q%q\" %s %f %{milli}dms"
catch_workers_output = yes
decorate_workers_output = no

; Security
security.limit_extensions = .php .php3 .php4 .php5 .php7 .php8
clear_env = no

; Performance tweaks
rlimit_files = 65535
rlimit_core = unlimited

; PHP settings
php_admin_value[error_log] = /var/log/php8.3-fpm/error.log
php_admin_flag[log_errors] = on
php_admin_value[memory_limit] = 128M
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 32M
php_admin_value[max_execution_time] = 30
php_admin_value[session.gc_maxlifetime] = 1440

3. 追加設定

ログディレクトリが存在しない場合は作成します：

mkdir -p /var/log/php8.3-fpm

3.1 設定に関するコメント

• listen = 127.0.0.1:9000 - nginxの設定と一致する必要があります（またはその逆）。
• pm.max_children = 50 - 利用可能なRAMに依存します（子プロセス1つあたり50MB → PHPで約2GB）。
• pm.start_servers = 10 - pm.max_children`の約20％。
• pm.max_requests = 500 - メモリリークを防ぐため、500リクエスト後にワーカーを再起動します（訪問者には気づかれず、動作に影響しません）。
• request_terminate_timeout = 30s - ハングしたリクエストを終了します。
• request_slowlog_timeout = 5s - 遅いリクエストを記録します。
• slowlog = /var/log/php8.3-fpm/slow.log

CMSベースのサイトの場合、遅いリクエストログは呼び出しスタックを表示するためあまり役に立たないかもしれませんが、リクエストの開始と終了の時間間隔に関する有用な情報を提供できます。

/fpm-status をモニタリングするには、nginxのサーバーブロックに以下を追加します：

    location = /fpm-status {
        allow 127.0.0.1;    # ローカルアクセスのみを許可
        allow 192.168.10.100; # または信頼できるネットワーク
        deny all;          # その他すべてを拒否

        include /etc/nginx/fastcgi_params;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $request_filename;
    }

出力内容は以下の通りです：

pool:                 www
process manager:      dynamic
start time:           04/Jun/2025:18:16:50 +0000
start since:          814
accepted conn:        239
listen queue:         0
max listen queue:     0
listen queue len:     128
idle processes:       9
active processes:     1
total processes:      10
max active processes: 3
max children reached: 0
slow requests:        0

4. 新しい設定の適用

設定ファイルにエラーがあるか確認します：

php-fpm8.3 -t

エラーがなければ、サービスを再起動します：

systemctl restart php8.3-fpm

5. 再テスト

新しい設定で同様のテストを行ったところ、CPU負荷が顕著に増加しましたが、性能は数分後に20％のみ低下（秒間9リクエストから7リクエストへ）し、安定しました。すべてのリクエスト（25分間で約10,000リクエスト、つまり1分あたり400リクエストまたは秒間約7リクエスト）はステータスコード200で正常に処理されました。

同時テスト中にウェブサイトのページを閲覧したところ、視覚的にパフォーマンスが明らかに向上しました。このウェブサービス構成により、サーバーリソースは以前のようにアイドル状態になることなく完全に活用されています。