refirio.org

概要

ミドルウェアやWebアプリケーションについてのチューニング例 ただし2022年現在、それぞれを細かくチューニングするよりも ・サーバのスペックを上げる ・サーバの台数を増やす ・データをキャッシュする ・CDNを導入する といった対応の方が手っ取り早い可能性がある チューニングが無駄ということは無いと思うが、焼け石に水だったり、構築内容を無駄に複雑にしてしまう可能性もある チューニングをする前に、それらも含めて検討する

Webアプリケーション チューニング

Webアプリケーションへの同時アクセス対策メモ http://refirio.org/view/367 Apache Benchを使った負荷テストのやり方 | Web活メモ帳 https://blog.verygoodtown.com/2012/05/apache-bench-ab/ ab コマンドすると、SSL read failed (5) - closing connection | クズリーマンのカス備忘録 https://it-afi.com/apache/ab-%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%99%E3%82%8B%E3%81%A8%E3%80%8... abツールを使うことで、大量アクセスが発生したときの状況をある程度再現できる SSL環境に対しては ab ではなく abs とすることで実行できる 具体的には、以下のようになる ApacheBenchmark(ab)実行中に問題発生：SSL read failed - closing connection https://teratail.com/questions/2180 「SSL read failed (5) - closing connection」これ自体はabsツールの不具合？詳細はまた調べたい PHPでは microtime() で実行時間を調べることができ、memory_get_usage() や memory_get_peak_usage() で、使用メモリ量を調べることができる http://refirio.org/memos/php/benchmark/ http://refirio.org/memos/php/benchmark/benchmark.php http://refirio.org/memos/php/benchmark/memory.php MySQLのExplainを確認する http://woshidan.hatenablog.com/entry/2015/06/20/165817 MySQLのexplainとかについてしらべたときのメモ http://qiita.com/lastcat_/items/de7b530a94fbcf9ba646 MySQLのEXPLAINを徹底解説!! http://nippondanji.blogspot.jp/2009/03/mysqlexplain.html なぜ、SQLは重たくなるのか？──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 https://employment.en-japan.com/engineerhub/entry/2017/06/26/110000 MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる http://blog.kamipo.net/entry/2018/03/22/084126 Linuxコマンドでボトルネックを調べる // Speaker Deck https://speakerdeck.com/pyama86/linuxkomandodebotorunetukuwodiao-beru

Apache チューニング

※preforkでのチューニング例 開発サーバや会員しか使わないサイトなら、設定する意味は少ない 短期間にApacheのプロセス数が大きく波打つようなサイトならチューニングが有効 （プロセスを作成するときの負荷を無くせるので） 基本的にはpreforkの設定はデフォルトのままで大丈夫 ※Apacheに標準で付属している Apache Bench で、負荷テストができる ※Apacheの設定ファイル httpd.conf を編集してチューニングする ※Apache Bench でのテストを飛ばして、はじめからメモリ量をもとに考えても良さそう 【初心者向け】ApacheBench入門 ｜ DevelopersIO https://dev.classmethod.jp/tool/ab-tutorial/ Apache Benchを使った負荷テストのやり方 http://blog.verygoodtown.com/2012/05/apache-bench-ab/ 同時接続数（MaxClients）をいくつに設定すべきか？ http://canalize.jp/archives/006925.php Apache Benchでサクッと性能テスト http://qiita.com/flexfirm/items/ac5a2f53cfa933a37192 404 Blog Not Found:tips - Webサーバーの負荷テストならまずab http://blog.livedoor.jp/dankogai/archives/51212610.html Apacheをインストールすれば自動的に使えるようになっているが、nginx環境などの場合は以下でツールのみインストールできる Nginx を使っているウェブサーバで ab(ApacheBench)コマンドを入れる | tamulab.jp https://tamulab.jp/install-apache-bench-on-nginx-webserver/ XAMPPの場合、C:\xampp\apache\bin 内に ab.exe が存在している Webアプリケーションへの同時アクセス対策メモ http://refirio.org/view/367 ■Apache Bench の実行例 以下のようにするとkeepaliveの状態でテストできる keepaliveの概要は以下のとおり ・接続を維持したまま複数のデータ転送を行える ・有効にすると通信が早くなる ・HTTP 1.1ではデフォルトで有効になっている キープアライブ - Wikipedia https://ja.wikipedia.org/wiki/%E3%82%AD%E3%83%BC%E3%83%97%E3%82%A2%E3%83%A9%E3%82%A4%E3%83%96 HTTP-KeepAliveとは - コトバンク https://kotobank.jp/word/HTTP-KeepAlive-10754 ■負荷テスト 1秒間に処理できるリクエスト数（Requests per second）がどんどん小さくなり、 1リクエストあたりの処理時間（Time per request）がどんどん多くなっている これは、リクエストが多くなると処理待ちが多く発生するようになるため。 Apache Bench でのアクセスは、完全な同時アクセスではない 最初はアクセスが少なく、だんだん増えていき、一定数が続き、徐々に減っていく。という実際のアクセスを再現する つまり、上の結果から「秒間200アクセスをさばくサーバ」と言えるわけでは無い 「200人の同時アクセスに耐えられるようにしてほしい」 の要件があった場合、 「秒間200アクセスをさばく」という意味なのか「200人が一定時間をかけて色々なページを見ている状況」 なのか確認しておく必要がある 普通のサーバなら、同時にさばけるのはせいぜい秒間数十くらい？ 秒間100などという数字が出てきた時点で、ロードバランサでの複数台構成を考える？ ネットワークも考慮できる分、Apache Bench ツールよりLoadImpactの方が便利 だた、他のサーバからabツールを使えばネットワークを考慮に入れられる Abを利用した負荷テスト時にTimeoutになる場合の対処法 http://qiita.com/y-mori/items/83547f4dd604e8e5c509 「TCP: time wait bucket table overflow」や「nf_conntrack: table full, dropping packet.」のエラーメッセージは無かった。 トップページへのリクエストなら大丈夫なので、負荷が高いページヘのリクエストだから問題があった？ 今度は、普通のHTMLページに対してリクエストしてみる CentOS6などでdmesgにpossible SYN flooding on port(SYN flooding警告)が出た場合の対策方法を考えてみるテスト http://triplesky.blogspot.jp/2014/07/centos6dmesgpossible-syn-flooding-on.html 受け付けられないほどの大量アクセスが来たというログが残っている。 このサーバの接続可能数の飽和点は500程度。余裕を持たせて400程度 また先にテストしたように、PHPプログラムのページの場合は210程度が限界 ただしそのまま210に設定すると、他のサービスが稼働できないくらいの接続を受け入れてしまう可能性がある また、swapも多発してサーバが非常に重くなる可能性がある 実際、abツールで計測している最中はサーバが非常に重くなった。 この状態ではサーバが落ちていなかったとしても「210をさばける」と言うわけにはいかない ■メモリ量からMaxClientsの目安を考えてみる 同時接続数（MaxClients）をいくつに設定すべきか？ http://canalize.jp/archives/006925.php MaxClients＝使用可能なメモリ量/Apacheの1プロセスが使用するメモリ量 という考え方で計算できる refirio.netサーバではメモリは1GBで、実際に使っているのは500MBくらい。 psで見ると、httpdの1プロセスが2%くらいを使っているので、1プロセスあたり10MBくらい使っている よって、MaxClientsは90〜100くらいが良さそう ↑の数値はRではなくSのプロセスだし、データベースなども考慮する必要がある。 常時立ち上げるなら80くらいでもいいかも？ （ただし例えばMySQLを使うなら、MySQLのmax_connectionsとの兼ね合いも考慮する） Sのプロセスでメモリの消費量を計算すると、実際はもっと消費する可能性があるので注意 ある程度サーバに負荷をかけてRのプロセスを表示させ、それをもとに計算した方がいい #なお、某大学の入試サイトサーバではメモリは16GBで、実際に使っているのは1.4GBくらい。 #psで見ると、httpdの1プロセスが0.1%に満たないくらいを使っているので、1プロセスあたり1.4MBくらい使っている #refirio.netとは大きく差があるが、1プロセスあたりの消費メモリは、実行されているプログラムによっても変わる #また、長い間プロセスが使われていないとメモリ量はどんどん小さくなるらしい #このサーバはスペックが高いので、他のプロセスが使われないので、最小状態になっている？ #Apacheの使用メモリが搭載メモリ数を超えてしまうと、スワップが発生してサーバが重くなる #逆に少なすぎると503エラーになる /etc/httpd/conf/httpd.conf を編集 一旦以下のように変更する これで様子を見つつ、エラーログに以下のメッセージが記録されたら、400までの値で少しづつ上げて調整する [error] server reached MaxClients setting, consider raising the MaxClients setting 400まで上げてもエラーログがでるようなら、もうその１台のサーバでは対応できない（Apache的に）ので、 ロードバランサで複数台構成を検討する必要がある また、これはあくまでもサーバスペックのみでの話。実際には転送量制限や帯域制限もあるので注意。 Apacheのチューニングメモ http://qiita.com/nownabe/items/1111cc32da9fe63289f0 中規模サイトのApacheチューニング http://qiita.com/kou/items/acb3dcf1dcb428d7a3ec 他にも以下を設定しておくと良さそう Timeout ... 60秒でも長い？10秒くらいでいいかも（ただしAWSの場合は120に設定する） KeepAlive ... OFFでよさそう（AWSの場合は有効に設定する） Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。 https://debiancdn.wordpress.com/2012/06/14/amazon-elb%E3%82%92%E3%81%86%E3%81%BE%E3%81%8F%E3%81%A4%E... ※今はサーバスペックが向上しているので、回線（帯域）の方がネックになることがある 帯域をもとに同時にさばける数を計算し、それをもとに判断するという手段もある ※サーバ契約前・構築前ならどのように判断する？ ■負荷をかけずに速度計測 以下のように「-c 1」にすれば単一の接続になる また、リクエストの回数も「-n 10」と少なめにする Netlifyが日本からだと遅い - id:anatooのブログ https://blog.anatoo.jp/2020-08-03

nginx チューニング

nginxの基本設定を改めてちゃんと調べてみた - Qiita https://qiita.com/hclo/items/35f00b266506a707447e 開発サーバーでもこれだけはやっておくnginxの設定 - Qiita https://qiita.com/yuse/items/fe05cec1a331306eac19 (コピペ)nginx最大パフォーマンスを出すための基本設定 https://gist.github.com/aliyome/d6a5e4bfb54985145b7297863c03aecb Nginxのパフォーマンスを極限にするための考察 - Qiita https://qiita.com/iwai/items/1e29adbdd269380167d2 nginxのパラメータチューニングとh2o - Qiita https://qiita.com/cubicdaiya/items/235777dc401ec419b14e 応答速度28.8倍。WordPressをApacheからNginxに移行して感じたブログ運営 http://hamako9999.net/apache2nginx/ NginxのRatelimit発動時に、安定したアクセスを提供するngx-smart-ratelimitを開発しました | ten-snapon.com https://ten-snapon.com/archives/2701 以下、いったんVagrant環境でデフォルト設定でベンチマークを取得したのみ ■計測前 ■計測（PHPで日時を表示するだけのページを計測） ■計測（インストール直後のLaravelホーム画面を計測。100人で計1000リクエスト） ※捌ききれている ■計測（インストール直後のLaravelホーム画面を計測。200人で計2000リクエスト。1回目） ※捌ききれていない ■計測（インストール直後のLaravelホーム画面を計測。200人で計2000リクエスト。2回目） ※捌ききれていない ■計測（インストール直後のLaravelホーム画面を計測。200人で計2000リクエスト。keepaliveあり。1回目） ※捌ききれていないが、先ほどよりは捌けている keepaliveによって、何らかの処理が省略されて負荷が減ったか ■計測（インストール直後のLaravelホーム画面を計測。200人で計2000リクエスト。keepaliveあり。2回目）

MySQL チューニング

※マシンの搭載メモリをもとに設定を調整する ※MySQLの設定ファイル my.cnf を編集してチューニングする ※MySQLのメモリ設定には、大きく分けて以下の2つがある グローバルバッファ ... mysqld全体で確保するメモリ スレッドバッファ ... コネクションごとに確保するメモリ MySQL 初めてのチューニング http://www.slideshare.net/Craftworks/my-sql-6113813 MySQLのmy.cnfファイルサンプル http://time-complexity.blogspot.jp/2013/10/mysqlmycnf.html MySQLの設定ファイル my.cnf をgithubにて公開しました & チューニングポイントの紹介 http://blog.nomadscafe.jp/2012/10/mysql-mycnf-github.html /etc/my.cnf で設定できる 以下のように設定を調整（WebサーバとDBサーバは共通で、搭載メモリは1Gとする） 設定内容の妥当性を確認する stack_sizeはコネクションごとに確保される領域。バイナリパッケージの種類によっては変更できないものもあり、256K固定と考えて良さそう 64bitマシンの場合、以下の式が搭載メモリの8〜9割程度になるように（DB専用サーバでないなら7割程度にする） 32bitマシンの場合、以下の式が2GBに近いもしくは上回っていると危険（32bitマシンではソフトに割り当てられるメモリは2Gまでだから？） 上の設定だと、最大747MのメモリがMySQLに割り当てられることになる スペック（メモリ）が変われば innodb_buffer_pool_size と innodb_log_file_size の値を変更し、それに合わせて max_connections も変更する 他の値も一通り見直す メモリ1Gのサーバなら、以下くらいに抑えてもいいかも？実験中 MySQLからの結果によってページを出力する場合、Apache的に同時接続数80に耐えられたとしても max_connectionsが65なら同時接続数65までにしか対応できないので注意 MySQLのチューニング http://nohohonlab.exblog.jp/i2 一旦ApacheのMaxClientsと同じ値で良さそう その設定でメモリ不足になるなど問題があるようなら、ApacheのMaxClients側の値を減らす wait_timeoutも設定する？その場合、ApacheのTimeoutと同じ値でいい？ チューニングではないが、以下の値も明示的に設定しておくといいかも？ max_allowed_packet インポート時に「MySQL server has gone away」が発生したときの対処 http://company.nankikumano.jp/contents/tech_info/104/ ■設定変更時のエラー対策 MySQLのinnodb_log_file_sizeを設定して再起動（service mysqld restart）しようとするとエラーになる InnoDBは my.cnf で指定された innodb_log_file_size の値と実際のログファイルのサイズが異なるとエラーにするらしい ただし、そのファイルが存在しなかった場合は再作成してくれるらしい よって以下の手順で変更する これなら大丈夫だった MySQLのinnodb_log_file_sizeを変更したらMySQLが起動しなくなった - /dev/null http://gitpub.hatenablog.com/entry/2013/08/02/001600 innodb_log_file_size のサイズを変更するには - Enjoi Blog http://blog.enjoitech.com/article/196

ec2-bench

※未検証 ec2-benchを利用し、t2.microのインスタンスを同時に10インスタンス起動させ、 各WebサーバのPHPプログラムに対し、一斉にApache Benchを実行して計測を実施。 ※以下の条件は、全て1インスタンスあたりのもの。(x10インスタンスで同時にリクエスト) 条件：同時リクエスト数：10 全リクエスト数：200 instance_type="t2.micro" instance_count="10" request_number="200" client_number="10" 結果：CPU使用率：90% ディスクスワップ：秒間約2.3MByte程度のスワップが発生。 条件：同時リクエスト数：5 全リクエスト数：200 instance_type="t2.micro" instance_count="10" request_number="200" client_number="5" 結果：CPU使用率：75% ディスクスワップ：部分的に、秒間30kbyte程度のスワップが発生。 所見：瞬間同時アクセス数が100になると、Apacheの起動中プロセスだけでは追いつかず、 新たなプロセスの追加起動が必要な分、一気にディスクスワップが発生してしまい、 CPU使用率が90％を超えてしまうため少々危険。 ただし同時アクセス50の場合は、ある程度落ち着いており、 計測中のブラウザアクセスでも、体感的な表示の遅延がないことから、 サーバダウンの心配はないと考えられる。 ※上記結果は全て、ロードバランサを通していない1インスタンスでのものなので、実運用においてはほぼ問題ない。 以上のことから、インスタンスタイプを保険でt2.smallにしておくことで、 問題無くサーバダウンの回避は可能だと判断できる。 Amazon EC2 を使った負荷テストツール "ec2-bench" を作りました http://blog.manabusakai.com/2014/07/ec2-bench/

動作確認

ひととおりの設定が終わったら、実際のコンテンツもしくは実際のコンテンツに近いものを設置する データベースにはダミーデータを大量に登録するなど、実際のものに近づける その上で、ロードインパクトや外部サーバからのabツールで実際に攻撃してみて、問題ない範囲を探る ・1ヶ月あたりもしくは1日あたりどれくらいのPVに耐えられるか？ ・1秒間にどれくらいのアクセスに耐えられるか？ 負荷テストについては Test.txt を参照

参考

秒間100万クエリ・8万リクエストの「グラブル」安定稼働を支える、Cygames「3つの取り組み」【デブサミ2017】 (1/2)：CodeZine（コードジン） https://codezine.jp/article/detail/10044 秒間100万クエリを受け付ける大規模ソーシャルゲームのバックエンドDBシステムの設計・運用ノウハウ // Speaker Deck https://speakerdeck.com/cygames/miao-jian-100mo-kueriwoshou-kefu-keruda-gui-mo-sosiyarugemufalsebatu... モンストを支えるインフラの今とこれから // Speaker Deck https://speakerdeck.com/isaoshimizu/monsutowozhi-eruinhurafalsejin-tokorekara ドラゴンクエストXは「世界は一つ」を実現するためにどのようなサーバ構成にしているのか？ - GIGAZINE http://gigazine.net/news/20120824-dragonquest-backstage-cedec2012/ Nianticの求人から推測する『Pokemon GO(ポケモンGO)』のサーバ構成 - Qiita https://qiita.com/shibacow/items/1ac6f65100252b78a707 Amazon AWSでユーザ数1100万以上にスケーリングするためのビギナーズ・ガイド | POSTD https://postd.cc/a-beginners-guide-to-scaling-to-11-million-users-on-amazons/ Amazon CloudFront の デフォルト上限値が更に大幅にアップしました！(2016秋) ｜ Developers.IO https://dev.classmethod.jp/cloud/aws/cloudfront-limit-update-201610/ MySQLのメモリー使用量を最適化する設定のベストプラクティス | Yakst https://yakst.com/ja/posts/3983