問題タブ [capacity-planning]

1 つの Web サーバーで処理できるトラフィックの量は? 私たちがそれを超えているかどうかを確認する最良の方法は何ですか?

数百人のユーザーを持つ ASP.Net アプリケーションがあります。その側面はかなりプロセッサを集中的に使用しますが、これまでのところ、SqlServer とサイトの両方を実行するサーバーが 1 つだけで問題ありませんでした。Windows Server 2003、3.4 GHz、3.5 GB の RAM を実行しています。

しかし、最近、私はさまざまな時期に速度低下に気付き始めました.アプリケーションの使用によってサーバーが過負荷になっているのか、それともアプリケーションを修正するために何かをする必要があるのか​​ を判断する最良の方法は何だろうと思っていました.ボックスに期待しすぎている場合は、小さな最適化を探すのに本当に多くの時間を費やしたいと思います)。

直線の行とテーブルのサイズを見積もるのはかなり単純な計算ですが、各インデックスが（特定のテーブルサイズに対して）どのくらいのスペースを占めるかを推測するのは難しいと思います。インデックスのより良い見積もりと成長率を計算するために、どの分野を学ぶことができますか？

SQL データベース内のテーブルの 1 つで、1 ナノ秒あたり 2 ニブルの増加率があります。1 日あたり何メガバイトなのか気になりましたが、心配する必要はありますか? 私のハードディスクは150GBです。

Catalyst Web アプリケーションからのアクセス ログを分析する作業を行っています。データは、Web ファームの前にあるロード バランサーからのもので、1 日あたり合計約 35Gb です。これはHadoop HDFS ファイルシステムに保存されており、 MapReduce を ( Dumbo経由で、これはすばらしい) 使用して数値を処理します。

分析の目的は、キャパシティ プランニング、最適化、およびシステムを監視するためのしきい値。Analog のような従来のツールは、最も要求の多い URL や最も使用されているブラウザーを教えてくれますが、どれも役に立ちません。/controller/foo?id=1984それが最も人気のある URL であることを知る必要はありません。へのすべてのヒットのヒット率と応答時間を知る必要が/controller/fooあるため、最適化またはキャッシュの余地があるかどうかを確認し、このアクションのヒットが突然 2 倍になった場合に何が起こるかを見積もることができます。

MapReduce を使用して、データを期間ごとのアクションごとのリクエストに簡単に分割できます。問題は、それをわかりやすい形式で表示し、重要な傾向や異常を見つけ出すことです。私の出力は次の形式です。

つまり、キーは期間であり、値は(action, hits, cache hits)期間ごとのタプルです。（これに固執する必要はありません。これは、これまでのところ私が持っているものです。）

約250のアクションがあります。それらを組み合わせて少数のグループにすることはできますが、各アクションのリクエスト数 (または応答時間など) を同じグラフにプロットすることはおそらくうまくいきません。第一に、ノイズが多すぎます。第二に、絶対数はあまり重要ではありません。頻繁に使用される軽量でキャッシュ可能な応答に対するリクエストが 100 リクエスト/分増加することは、100 リクエスト/分増加することよりもはるかに重要ではありません。めったに使用されないが高価な（おそらくDBにヒットする）キャッシュ不可能な応答で。同じグラフでは、ほとんど使用されていないアクションに対する要求の変化は見られません。

静的なレポートはあまり良くありません。膨大な数の表は、消化するのが困難です。時間単位で集計すると、重要な分単位の変化を見逃す可能性があります。

助言がありますか？この問題をどのように処理していますか? 1 つの方法は、リクエストの割合またはアクションごとの応答時間の大幅な変化を強調することだと思います。ローリング平均と標準偏差がこれを示しているかもしれませんが、もっと良いことはできますか?

他にどのような指標や数値を生成できますか?

私が読んだり経験したことすべて (Tornado ベースのアプリ) から、ePoll は Select および Poll ベースのネットワーク、特に Twisted を自然に置き換えるものであると確信しています。より良いテクニックや方法論に代償が伴わないことはめったにありません。

epoll と代替品の数十の比較を読むと、epoll が明らかに速度とスケーラビリティのチャンピオンであることがわかります。そうは言っても、プロセッサとメモリの使用率はどうですか? epoll は依然としてチャンピオンですか?

クライアントのサイジングと容量計画を実行するように求められることがよくあります。当社のクライアントが当社の製品 (基本的には J2EE Web アプリケーション) を購入するとき、それらの製品を実行するために必要なハードウェアをよく尋ねられます。私たちの推奨事項は、多くの場合、高額なハードウェアの取得につながります。

これまでのところ、私が開発した最良のヒューリスティックは、使用予測 (アプリケーションが参加する必要がある登録ユーザーと同時ユーザーの数) を、既存のインストールで収集されたデータと比較することです。例: インストール A が X ハードウェアを使用して 100 人の同時ユーザーに対応する場合、インストール B には 200 人の同時ユーザーに対応するために 2*X ハードウェアが必要です。

ただし、このアプローチには多くの問題があります。多くの場合、クライアントは異なるハードウェアおよびソフトウェア プラットフォームを使用します。彼らが私たちから購入する製品のセットは、通常決して同じではなく、通常、アプリケーションの一部は特定のクライアントの注文に基づいて構築されます。ソフトウェアのバージョンが変更されていることや、サイジングのタスクを非常に困難にするパラメータが非常に多いことを考慮してください。

私はこのテーマに関する本をいくつか調べましたが、複雑な数学的モデルを使用することを提案しているものもあります。これらのアプローチが入力として必要とするパラメーターの数 (たとえば、アプリケーション機能の詳細な分類) を考えると、これらはほとんど役に立たないと思います。ハードウェアは通常、基本的な要件が定義される前に注文されます。これらはアプリケーションの開発とライフサイクルを通じて変化することは言うまでもありません。では、サイジングとキャパシティ プランニングはどのように行うのでしょうか? ヒントやハウツーをいただければ幸いです。

ビデオエンコーディングサーバーの容量計画に役立てるために、変換に1分間のビデオがかかる時間を計算しようとしているため、FFMPEGプロセスをログに記録できるようにしたいと考えています。ログを有効にするにはどうすればよいですか。ログフ​​ァイルはどこに保存されますか。CentOSLAMPマシンにFFMPEGをインストールしています。

スタックオーバーフローのウェブサイトを開発したいとします。1日あたり100万件のリクエストを想定して、このWebサイトをサポートするために必要なコモディティハードウェアの量を見積もるにはどうすればよいですか。この状況で可能なパフォーマンスの向上を説明するケーススタディはありますか？

I / Oのボトルネックは、ほとんどのシステムの主要なボトルネックであることを私は知っています。I / Oパフォーマンスを改善するための可能なオプションは何ですか？私が知っているそれらのいくつかは

1. キャッシング
2. レプリケーション

低遅延アプリケーションのパフォーマンス チューニングとキャパシティ プランニングを行っていますが、次の質問があります。

光ファイバーを介して接続されたロンドンのホストとニューヨークのホストの間で送信されるパケットの理論上の最小往復時間は?