昨今では、サーバーサイド側はJSONをやりとりするだけのREST APIサーバーにして、フロントでJSをゴリゴリしてサイトを作るってのが流行ってますよね。
インケンが携わっているプロジェクトでも、PHPのAPIサーバーとフロントがBackbonejsという構成になっています。
今までの経験上、WEBサイトって大抵の場合DBがボトルネックになっているのですが、インケンが携わっているプロジェクトにてAPサーバーが悲鳴を上げだしたので、サーバーの設定を見直しました。
例えば、負荷が高まるとこんなエラーが出てきます。
Nginx /var/log/nginx/error.log
[error] 16347#0: *2141360 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx [error] 18897#0: *7931791 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xxx.xxx.xxx [error] 18898#0: *7866945 upstream timed out (110: Connection timed out) while reading response header from upstream, client: xxx.xxx.xxx.xxx worker connection not enough
だいたいどれも、コネクションが切れた、タイムアウトしたといったエラーです。
一番下のはわかりやすいですね。nginxのworkerコネクション数が足りないよって言われてます。
APIサーバーとJSといった構成の場合、どうしても通常のサイト（PHPがHTMLを吐き出して、AJAXをそこまで使用していないサイト）よりリクエスト数が増えます。
１ページ表示するのに、PHP側には10リクエスト以上飛んでくるってのもザラです。
なので、PV少なそうなのにMAXコネクションまで行ってるよ、、ってことがわりとあるんですね。
実際にインケンのプロジェクトでエラーが多発した時の対処をご紹介します。
参考スペック
APIサーバーのスペックはCPU４コア、メモリ14Gで、APIサーバーが２台、DBマスター１台、スレーブ２台、その他KVSやMQサーバーなどがあります。
月間PV1000万以上です。ピーク時のGoogle Analyticsのリアルタイム値が
１分間で200PV x 10 (_setSampleRateが10なので）
1ページで10のAPIリクエストがあるとすると、秒でざっくり330リクエスト飛ぶことになります。
設定値は各サーバーのスペックとか、同時アクセス数にもよるので、参考までに。
Nginxの設定
worker connection not enoughが出るような場合は、max値を上げましょう。
/etc/nginx/nginx.conf
events {
use epoll;
worker_connections 2048;
}
1024 → 2048にしました。
設定値はサーバーのスペック、アクセス数によって調整してください。
PHP-FPMの設定
104: Connection reset by peer , 111: Connection refused , 110: Connection timed outあたりのエラーは大抵PHPがボトルネックになっています。
/etc/php-fpm.d/www.conf
pm = static pm.max_children = 300 pm.max_requests = 1000
pm = staticは最初から小プロセスの起動数を固定する記述です。dynamicだと動的ですが、最初から確保できるstaticのがよさげです。
max_childrenは起動する小プロセスの最大数です。これが低くて足りないと502 Bad Gateway が多発します。だからといってむやみに多くしてもLoad Average増えちゃう予感！
max_requestsは子プロセスが、再起動するまでに実行するリクエスト数です。メモリと相談。
パラメーターの詳しい説明は、公式のドキュメントに載ってるので参考にしてください
それ以外の設定
それ以外で対応できることとしては、apcの設定を見なおしたり、/etc/sysctl.confの中身やら、nginxのkeepaliveやらをもろもろ確認したほうがいいと思います。
あとはリクエストをまとめたり、プログラムを見なおしたり
でも結局はスケールアウトした方がいいかも
インケンのプロジェクトでは、上記の設定に見なおしたのですが、それでも若干不安定だったので、結局はAPIサーバーをスケールアウトしました。
各サーバーの設定を見なおして、最適化するのも大事ですが、コスト面で都合がつけばスケールアウトしたほうがいいと思います。
