1分あたりいくつのリクエストが「重い負荷」と見なされますか？ （概算）
多くの場合、人々は（最適化とパフォーマンスに関連する）「重い負荷」についての質問と回答で話します。
典型的なサーバー上の通常のWebアプリケーションのコンテキストでこれを定量化しようとしています（SOとそのかなり小さなインフラストラクチャを例にとります）。すぐに戻ります（データベースの速度などを単純化して方程式から取り除くため）.
「CPUの限界」などではなく、公称数/範囲を探しています。おおよその概算は素晴らしいでしょう（例：> 5000/min）。ありがとうございました！
ハードウェアの負荷測定（CPU、メモリ、IO使用率））を望まない場合、これに対する適切な答えは、重い負荷が時間あたりの要求の量であることだと思います時間単位あたりの要求の最大必要量以上の単位。
必要なリクエストの最大数は、顧客またはアーキテクチャ全体を担当する担当者との間で定義されたものです。
Xは、アプリケーションに必要な最大負荷です。私はこのようなものが答えを近似すると思います：
0 <軽負荷<X/2 <通常の負荷<2X/3 <高負荷<X <=重負荷
薄い数字が1つしかないのは、アプリケーションとはまったく関係がないということです。そして、重い負荷が何であるかは、完全に、絶対的に、アプリケーションが何をすることになっているのか、不可解です。
1秒あたり200リクエストは、小さなWebサーバーをビジー状態に保つ負荷です（1分あたり12000）。
1秒あたり数百のリクエスト。
ほとんどのサーバーでの最初から開いている接続の数は、通常、1秒あたり約256以下のエルゴ256リクエストです。 pingリクエストの場合は2000-5000まで、軽量リクエストの場合は500-1000までプッシュできます。それをさらに高くすることは非常に困難であり、ネットワーク、ハードウェア、OS、サーバーアプリケーション、およびユーザーアプリケーション全体にわたって変更が必要です（ problem 10k を参照）。
HDDのシーク速度+レイテンシは約1〜10ミリ秒です。SSDの場合は0.1-1 msです。つまり、100-100 000 IOPSです。 100 000をトップ値としましょう（ SSD結果の書き込み ）
通常、接続は少なくとも1 x latency value msの間開いたままになります。クライアントからサーバーへのレイテンシがめったに50-100 msを下回らないため、100 000/50 = 2000 IOPSのみが新しい接続を作成できます。
したがって、異なるクライアントからの1秒あたりの2000 ping要求は、通常のサーバーの基本的な上限です。 RAMディスクの使用、またはIOPS数を増やすためのSSDの追加、pingを減らすためのルーティング要求、カーネルのオーバーヘッドを減らすためのOSの変更/変更などによって改善できます。通常、多くの理由により、同じクライアント（接続）からのリクエストであり、クライアントの数は限られています。良好な状態では、最大 数十万
一方、ping、アプリケーション実行時間、OSおよびハードウェアの欠陥が多いと、基本値が1秒あたり数百リクエストに簡単に減少する可能性があります。また、一般的なWebサーバーとアプリケーションは通常、高度な最適化にはあまり適していません。そのため、Vinko Vrsalovicの200の提案はかなり現実的です。
これは、単純な要求/分数で回答できる簡単な質問ではありません。
テレコム部門では、パフォーマンステストを頻繁に行っており、1秒あたりの実行コール数をシミュレートして、制限を調べています。サーバーが追いつかなくなるまで、コールレートを上げ続けます。
したがって、それはサーバーとサーバーが何を処理できるかに依存します。それはあなたの視点にも依存します。たとえば、古い386では、わずか50リクエスト/分しか処理できませんでした。私はそれを軽い負荷と呼びます。しかし、高スペックのサーバーは60000リクエスト/分を処理できる可能性があります。これは推測です。 Apacheがこれを実行できるかどうかはわかりません。私たちの通信ソフトウェアは確かにできます。
サーバーの観点からこれに答えることが最善だと思います。非常に重い負荷とは、サーバーが数分または数十分にわたって処理できる能力の10％以内に到達したときだと思います。 15％以内の高負荷。
負荷は単に単位時間あたりのリクエストの問題ではないため、答えるのは難しいです。それはそれらのリクエストが何をしているか、そしてそれらがどのように実装されているかに依存します。
たとえば、書き込みよりも読み取りが多いと、負荷が軽くなる可能性があります。
書き込みの非同期処理は、同期処理が完了するのを待つ必要よりも負荷が軽いことを意味する場合があります。
1つの極端な例は、取引日ごとに数十億のトランザクションを処理する株式取引システムです。 NYSEまたはNASDAQの標準的なボリュームを見て、それを使用して1分あたりの高い値を見積もります。
取引日の2B取引がNASDAQの代表であるとしましょう。市場は午前9時に開き、午後4時に閉じるため、7時間* 3600秒/時間= 25200秒です。これにより、平均2Bトランザクション/ 25200秒= 79,365トランザクション/秒-非常に高い負荷になります。彼らは明らかに多くのサーバーを使用しているので、サーバーごとの負荷を把握するには、その数が必要になります。
SOが適切なベンチマークと見なせる場合は、メタのボリュームについて質問する場合があります。
重い負荷は、要件に記載されているものよりも大きいものです。アプリケーションがどのように使用されて、何が高負荷となるかを判断する必要があります。そうしないと、食料品の生産にのみ使用されるフェラーリを構築してしまう可能性があります。素晴らしい経験ですが、リソースの浪費です。