問題タブ [capacity-planning]

開発チームのリソース キャパシティ プランニングを行うために、どの製品またはツールを使用していますか? 現在、大規模なグループを管理しており、リソースの可用性を可視化しようとしています。私はこれを MS プロジェクトで作成していますが、あなたの経験に基づいたより良いツール/ソリューションがあるかどうか興味がありました.

キャパシティ プランニングの目的でデータベース負荷を計算する方法について、いくつか考えてみました。質問はインフラストラクチャを定義するのではなく、アプリケーションだけを測定することに関連しているため、サーバー障害にはこれを入れていません。この場合、その少しを心配するのは他の誰かの仕事です!

ここには膨大な数の変数があることは承知していますが、他の人がどのようにして大まかな大きさの感覚を得ようとしているのかに興味があります. これは、特定の設計が作成される前のプロジェクト ライフサイクルの早い段階での単純なコスト計算の演習であるため、この段階では多くの情報を提供する必要はありません。

インフラ担当者からの質問は、「同時ユーザー数」です。この 1 つの数字だけを求める論理的根拠については議論しないでください。それはまさにこの場合に求められたものです!

これは Web フロント エンドであり、かなり固定された、簡単に定量化できるオーディエンスを持つ SQL Server バックエンドです。これを実際の同時リクエストに大雑把に当てはめると、私の見方では、ますます細分化された測定単位になります。

1. 総視聴者数
2. 同時セッション
3. 同時リクエスト
4. 同時DBクエリ

これは、Web アプリのキャッシュ、部分的なページ リクエスト、レコード ボリュームなどの要因を考慮しておらず、ユーザーごとのリクエストの頻度、DB ヒット数、実行時間を定義するために必要な創造的なライセンスがいくつかありますが、妥当な出発点のように思えます。また、ピーク負荷に合わせてスケーリングする必要があることも認識していますが、必要に応じて同時セッションにプラグインできる別のものです。

これは確かに非常に基本的なものであり、より包括的なガイダンスが存在すると確信しています。誰かがこの演習へのアプローチを共有したり、プロセスを少しアドホックにしない他のリソースを教えてくれたりすると、それは素晴らしいことです!

Java EEベースのeコマースWebサイトが良好に機能しており、期待される応答時間とスループットが得られているとします。WebサイトはUIの大幅な変更が行われており、3倍のトラフィックが見込まれます。

予測されたWebトラフィックを既存の環境で処理できるかどうかを確認するにはどうすればよいですか？

既存のシステムのシステム使用率（CPU、メモリ使用率）、スループット、応答時間がある場合、実際にシステムの負荷テストを行わずに、実験式を使用してそれを見つける方法はありますか？（目標は、設計段階でSLAを満たすことができるかどうかを判断することです）

私はオフィスに技術的負債台帳を設置していて、それをかなり包括的なツールにしたいと思っています。

記録すべき重要な情報は何ですか？

「明らかに十分に速い」ように見えたが、負荷がかかった状態でパフォーマンス的に吸い込まれたものに何度か燃やされた後、キャパシティプランニングを行うときの私の「直感」は十分ではないかもしれないと思い始めています。理論的な背景が必要です。

それで、コミュニティ、待ち行列理論のプログラミングへの応用に関する優れたリソースを教えていただけますか？

何でも-記事、ケーススタディ、本。

これまでに関連していると思われる本をいくつか見つけました。ご存知の方は、ぜひご意見をお聞かせください。

• ソフトウェアのパフォーマンスとスケーラビリティ：定量的アプローチ
• コンピュータシステムのパフォーマンス分析の技術：実験計画、測定、シミュレーション、およびモデリングの手法
• 設計によるパフォーマンス：例によるコンピューター容量計画

たまたまSQLServer2008の最大容量仕様を読んだところ、 1行あたり最大8060バイトでしたか？何...1行あたり8KBしか許可されていませんか？（はい、「行オーバーフローストレージ」の特別な処理を見ました。標準の動作について話しています）

私はここで何かを誤解しましたか？SQLServerデータベース内にいくつかのMBサイズのバイナリオブジェクトが格納されているのを見たと確信しているので、私は持っていると確信しています。この不吉な行ごとの意味は、実際には1行、複数列のようなテーブル行を意味するのでしょうか。

したがって、nvarchar4000文字ごとに3つの列がある場合（テキストボックスに3つの法的文書が書かれていると仮定します...）-サーバーは警告を吐き出しますか？

小さな AWS インスタンス (デュアル コア AMD、2.60 GHz、1.7 GB RAM) に ASP.net Web アプリケーションをデプロイしています。このサーバーで 300 人の同時ユーザーに対して負荷テストを実行したいと考えています。将来的には、アプリケーションの 250,000 人の登録ユーザー向けの暫定的なキャパシティ プランニングと展開アーキテクチャを設計したいと考えています。

私はこの分野では非常に新しい人であり、これまで負荷テストを行ったことがありません。

私のアプリケーションのユースケースとシナリオは次のとおりです。

シナリオ- データベースに 250,000 人の登録ユーザー

同時実行– 5% - 7% - 約 17,500

各ユーザーには本棚があり、各ユーザーが 10 冊の本を購読していると仮定します。各本は約 25 MB のサイズで、400 ページあります。

ユースケース

1. ユーザーログイン

   • データベースの認証と認可

2. 本の画像で本棚を見る

   • 本の棚 (.swf) - 400 KB (ユーザーごとに読み込まれます)

   • 10 冊の本の画像が読み込まれます (1 画像あたり 20KB)(約)

   • catalog.xml - ユーザーに割り当てられた 30 KB/ユーザー

   • 注: 約 650KB のデータがクライアント マシンにダウンロードされます。

3. ブックの参照 : ファイルに続くブックの画像をクリックすると、そのサイズがクライアント マシンにダウンロードされます

   • 一度
   • Reader.swf - 950 KB (最初のダウンロード)
   • 約 100 KB の XML データ / ブック (クリック時)
     • Book.xml
     • 注釈.xml
     • Catalog.xml
     • Usersettings.xml 40KB*4 = ユーザーあたり 160 KB (.swf)
   • 注: 約 1200KB のデータがクライアント マシンにダウンロードされます。

誰かがこれをどのように進めることができるか提案してもらえますか?

よろしくお願いします、アマール

もちろん、クライアントが遅すぎてサーバーの書き込みを読み取ることができない場合、データはバッファリングされて大きくなる可能性があります [1]。

しかし、デフォルトのバッファサイズは? /proc/sys/net/ipv4/tcp_rmem および tcp_wmem (Linux を想定) で構成されているものは何でもあると思います...

基本的な容量計画を実行しようとしています。512 MB の RAM を搭載した VPS があり、OS などが 100 MB まで使用すると仮定すると、私のアプリは何をするにも 400 MB まで使用できます。接続された各クライアント (通常の古い TCP/IP ソケット) がデフォルトで 8KB (読み取り 4KB、書き込み 4KB) を必要とする場合、400MB / 8KB = ~ 50000 クライアントの容量があります。

[1] http://nodejs.org/docs/v0.4.7/api/all.html#socket.bufferSize

「キャパシティプランニングの芸術」（BTW、気に入った）という本を読んだばかりですが、その中で著者は、サービスの測定、上限の確認、ニーズの予測、簡単な展開の確保などがいかに重要であるかを説明しています。 。しかし、本を通して、彼はFlickrでの彼の経験を説明しています。そこでは、彼は常に同じ製品に直面しなければなりません。

私たちの多くは、他の企業にとって中小規模のプロジェクト規模に直面している企業で働いています。私たちは彼らのビジネス、彼らのニーズを理解し、アーキテクチャ、モデルなどを計画する必要があります。

次に、お客様は「1000人のユーザーをサポートする必要があります」と言います。さて、ユーザーは1秒あたり何件のリクエストですか？彼らのセッションはどのくらいですか？彼らはどのくらいのデータを転送しますか？彼らはどの操作を実行しますか？彼らはどのくらいですか？

それらの数値を知ることができる場合もあれば（既存のアプリケーションを監視しているため、またはすでにその測定を行っているため）、不可能な場合もあります（現在のWebサイトがないため、または知ることができるため）。

サーバーの数、帯域幅、ストレージなどをどのように推測しますか？どの参照図を使用しますか？

よろしく。