9分 read (About 1345 words)
【読書メモ】Webパフォーマンスチューニング
Chapter1 チューニングの基礎知識
- 推測するな、計測せよ
- ボトルネックはどこか？CPU？メモリ？
- ネットワークIO？アプリ処理？データベースIO？など
Chapter2 モニタリング
- CPUやメモリの監視→モニタリング
totalコマンドやfree --humanコマンドでそれぞれの情報を確認できる- が、それだとその瞬間の値しか見れない
- 推移が見たいときは例えば1分ごとに実行し、結果を記録する必要がある
- 手動じゃ無理
- なのでツールに頼ろう
- 有名なのはPrometheus（プロメテウス）
- これは監視用のサーバーを別途立てて、そこにPrometheusを起動して、監視対象のサーバーに定期的にアクセスして結果を記録するやつ
- 監視対象先のサーバーにもPrometheusからのアクセスされるためのエンドポイントの用意が必要
- これはnode_exporterツールを使うと便利
- Prometheusはモニタリング結果のダッシュボード表示もできるよ
- ハマりがちな罠：CPUが複数ある場合、瞬間的な増減の見落としなど
Chapter3
- 負荷試験をやろう
- abコマンド（Apache Bench）が便利
- 指定したURLに指定した回数擬似リクエストできる
- topコマンドで、MySQL・Webアプリ・WebサーバーなどどれがCPUを多く使っているか確認しよう
- MySQLがボトルネックの場合、遅いSQL（スロークエリ）を特定しよう
- my.cnfのslow_query_logを1に設定すると表示される
- 対象のSQLが特定できたらEXPLAINで実行計画を確認しよう
- 必要に応じてインデックスを貼るなど検討しよう
Chapter4
- 単一のURLへの負荷試験に加えて、シナリオを持った負荷試験をやろう
- 例えばログインして、データを登録して、削除して、とか
- k6というツールで実現できる
Chapter5 データベースのチューニング
- RDBMSは一貫性があることが強み。データのロックがあるので。
- 性能重視ならNoSQLもあり。memcachedやRedisなど。
- インデックスは便利だけど多すぎるとデータの追加・更新の負荷が増えるので注意
- SQLに
EXPLAINをつけて実行計画を確認しよう
- SQL回数が多すぎるものはN+1問題を疑おう
- N+1問題の解決策として、キャッシュ、別SQL、JOINなどが有効
Chapter6 リバースプロキシの利用
- リバースプロキシはクライアントとアプリケーションサーバーの中継役
- リバースプロキシを置かない場合、大量リクエストが来た場合、通信が遅いクライアントに専有されたりしてしまう
- せいぜい1万リクエストが上限なのでC10K問題と呼ばれる
- 代表的なリバースプロキシがnginx
- gzipの設定などを行うことで高速化できる
Chapter7 キャッシュの活用
- キャッシュにはアプリケーションで作成するものと、クライアントによるHTTPレスポンス自体のキャッシュがある
- 本章ではアプリケーションによるキャッシュが対象
- 代表的なキャッシュアプリはmemcachedとRedis
- キャッシュをアプリケーションのメモリやファイルに保存する方法もあるが、並列の処理・有効期限・削除などに注意が必要
- ただ、キャッシュはデータの不整合（古いデータを表示してしまう）など処理が複雑になるデメリットがある
- キャッシュヒット、キャッシュミスの割合を監視して適切にキャッシュが使えているか監視しよう
Chapter8 押さえておきたい高速化手法
- 開発用の設定で冗長なログを出力しない
- 画像データをMySQLではなく静的ファイル配信しよう
- urlにランダム文字列を付与（app.js?v=ramdom_stringなど）することでキャッシュを利用されないようにできる（キャッシュバスター）
- HTTPヘッダーを活用してクライアント側にキャッシュさせる
- cssはjsファイルなどはあまり変更ないのでキャッシュさせたい
- If-Modified-Sinceヘッダーなどを利用しよう
Chapter9