1

Web ポータルのすべてのページに対して、ページ全体を処理するのにかかった時間に対して、一種の code_ping を使用しています。

現在のタイムスタンプで初期化されたヘッダーで $count_start を実行し、フッターで $count_end を実行すると、同じように、ページがどの程度最適化されているかを大まかに知るためのメーターです (クエリ、すべての読み込み時間)その特定のページで）。

あるページでは 0.0075 秒、他のページでは 0.045 秒などとします...この方法でクエリをより適切に最適化することに取り組んでいます。

私の質問はです。1 つのページがこのメーターで 0.007 秒の「おおよその読み込み時間」と言う場合、1000 人のユーザーが同じページを同時にクエリすると、それぞれ 0.007 * 1000 = 7 秒で結果が得られますか? 彼らはそれぞれ7秒後にページを取得することを意味しますか?

ありがとう

4

1 に答える 1

4

幸いなことに、通常はそうではありません。

式に欠けている変数は、データベース、アプリケーション サーバー、およびスタック内のその他の要素が同時実行をどのように処理するかです。

これを MySQL の観点から厳密に説明するために、MySQL サーバーへの一定数の接続をそれぞれ独自のスレッドで確立するテスト クライアント プログラムを作成しました (したがって、ほぼ同時にサーバーにクエリを発行できます)。 .

すべてのスレッドが接続されていることを知らせると、すべてのスレッドに同時にメッセージが送信され、クエリが送信されます。

各スレッドが "go" シグナルを受け取ると、現在のシステム時刻を調べて、クエリをサーバーに送信します。応答を受け取ると、システム時間を再度確認し、すべての情報をメイン スレッドに送り返します。メイン スレッドはタイミングを比較し、以下の出力を生成します。

このプログラムは、サーバーへの接続を確立するのに必要な時間をカウントしないように記述されています。これは、適切に動作するアプリケーションでは接続が再利用可能であるためです。

クエリはSELECT SQL_NO_CACHE COUNT(1) FROM ...(約 500 行の InnoDB テーブル) でした。

threads  1 min 0.001089 max 0.001089 avg 0.001089 total runtime 0.001089
threads  2 min 0.001200 max 0.002951 avg 0.002076 total runtime 0.003106
threads  4 min 0.000987 max 0.001432 avg 0.001176 total runtime 0.001677
threads  8 min 0.001110 max 0.002789 avg 0.001894 total runtime 0.003796
threads 16 min 0.001222 max 0.005142 avg 0.002707 total runtime 0.005591
threads 32 min 0.001187 max 0.010924 avg 0.003786 total runtime 0.014812
threads 64 min 0.001209 max 0.014941 avg 0.005586 total runtime 0.019841

時間は秒単位です。最小/最大/平均は、同じクエリを実行して観察された最良/最悪/平均時間です。同時実行数が 64 の場合、最良のケースは、クエリが 1 つしかない最良のケースとそれほど変わらないことがわかります。しかし、ここでの最大のポイントは、総実行時間の列です。その値は、最初のスレッドがクエリを送信したときからの時間の差です (すべてのスレッドが本質的に同時にクエリを送信しますが、「正確に」同じ時間は不可能です。 test script on) を、最後のスレッドがその応答を受信したときまで。

観察: 良いニュースは、平均 0.005586 秒かかる 64 のクエリは、実行に 64 * 0.005586 秒 = 0.357504 秒を必要としなかったことです... 64 * 0.001089 (最良のケースの時間) = 0.069696 すべてを必要としませんでした。これらのクエリの開始と終了は 0.019841 秒以内でした... または、理論的には、次々と実行するのにかかる時間の約 28.5% にすぎません。

もちろん、悪いニュースは、このクエリの同時実行数 64 での平均実行時間は、1 回だけ実行した場合の 5 倍以上であり、最悪の場合はほぼ 14 倍になることです。しかし、これは、単一クエリの実行時間からの線形外挿が示唆するよりもはるかに優れています。

ただし、物事は無期限にスケーリングされません。ご覧のとおり、パフォーマンスは並行性によって低下し、最初に発生したボトルネックに到達すると、ある時点で (おそらくかなり急速に) 低下します。ストレージのパフォーマンス、システムのメモリのサイズ、パフォーマンス、アーキテクチャ、およびMySQL の内部 - 調整できるものとできないものがあります。

もちろん、データベースだけが要因ではありません。アプリケーション サーバーが同時要求を処理する方法は、負荷がかかった状態でのパフォーマンスのもう 1 つの大きな部分であり、データベースよりも大きい場合もあれば、小さい場合もあります。

ベンチマークから不明な点の 1 つは、データベースがクエリに応答するのにどれくらいの時間が費やされているか、アプリケーション サーバーがロジック ビジネスを実行するのにどのくらいの時間が費やされているか、およびアプリケーション サーバーがロジック ビジネスを実行するのにどのくらいの時間が費やされているかということです。ページの結果を HTML にレンダリングします。

于 2013-07-26T19:54:47.970 に答える