高負荷サイトのボトルネックを見つけるには : DSAS開発者の部屋
はじめに アクセスが急増すると、応答時間が著しく悪化するサイトはありませんか？ 普段は200ミリ秒以内で安定してアクセスをさばいているのに、イベントやらキャンペーンやらを開始した瞬間から、普段の２倍や３倍のアクセスが殺到し、その結果、レスポンスタイムが3秒とか9秒とかかかるようになってしまうことってありますよね。 あるサイトの実状 つい先日まで、そんなサイトが私の目の前にもありました。自社で運営している某ソーシャル系のサイトなんですが、イベント開始時刻と同時にアクセス数が急増するのです。とはいえ、所詮は普段の2倍とか3倍程度の数なのだから、少なくとも1秒以内にレスポンスを返せるくらいの性能は維持したいものです。 しかし実際は困ったことに、応答に3秒以上もかかってしまう処理が大量に発生してしまう状況に陥ってしまっていました。これはきっと、どこかにボトルネックがあるに違いありません。 仮説を立
メトリクス可視化から始める Rails ウェブサーバーのチューニング by s4ichi - Kaigi on Rails 2021
Puma や Unicorn といったウェブサーバーは、Rails アプリケーションをハイパフォーマンスに運用するために欠かせない存在です。これらを適切に設定することはパフォーマンス面で利点がある他、アプリケーションが動作するホストのリソースを効率良く活用することができるため、コストの削減に繋がる可能性があります。しかしながら、サーバーのプロセスやスレッド数の設定ひとつをとっても、動作環境やサービスのアクセス傾向に応じて設定すべき値も変わってくるため、秘伝の設定ですべて事足りるとも限りません。 本セッションでは Puma や Unicorn からメトリクスを収集・可視化し、Rails アプリケーションをチューニングしていく事例を紹介します。CPU やメモリの状況といった標準的なメトリクスはもちろん、ウェブサーバー特有のメトリクスも利用してチューニングするプロセスを、アクセス傾向が異なる複数
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
