3

効率を測定しようとしているスクリプトを作成しようとしています。いくつか質問があります:-

  1. 小規模なアプリケーションの場合、この種のプロファイリングは必要ですか? それとも私は妄想的になっていますか？(ほとんどのコードが適切に効率的である/無限ループがないことを前提としています)
  2. これを何に対してベンチマークする必要がありますか？何と比較すればよいですか？
  3. 以下は、ab から取得した効率出力です。このやり方はずれすぎですか？このアプリの設計は間違った方向に向かっていますか? 注意すべき警告信号はありますか?
abs -n10000 -c100 http://localhost/testapp

これはApacheBench、バージョン2.3です
Copyright 1996 Adam Twiss、Zeus Technology Ltd、http://www.zeustech.net/
The Apache Software Foundation にライセンス供与 (http://www.apache.org/)

ローカルホストのベンチマーク (しばらくお待ちください)
1000件の依頼を完了
2000件の依頼を完了
3000件の依頼を完了
4000件の依頼を完了
5000件の依頼を完了
6000件の依頼を完了
7000件の依頼を完了
8000件の依頼を完了
9000件の依頼を完了
10000 件のリクエストを完了しました
10000 件のリクエストを完了しました


サーバー ソフトウェア: Apache/2.2.10
サーバーのホスト名: localhost
サーバーポート: 80

ドキュメント パス: /testapp
ドキュメントの長さ: 525 バイト

同時実行レベル: 100
テストにかかった時間: 33.608 秒
リクエストの完了: 10000
失敗したリクエスト: 5179
   (接続: 0、受信: 0、長さ: 5179、例外: 0)
書き込みエラー: 0
合計転送: 6973890 バイト
HTML 転送: 5253890 バイト
1 秒あたりのリクエスト数: 297.55 [#/秒] (平均)
リクエストあたりの時間: 336.080 [ms] (平均)
リクエストあたりの時間: 3.361 [ms] (すべての同時リクエストの平均)
転送速度: 202.64 [Kbytes/sec] 受信

接続時間 (ミリ秒)
              最小平均[+/- sd] 中央値最大
接続: 0 1 1.5 0 109
処理: 8 334 403.9 176 3556
待機中: 7 334 403.9 176 3556
合計: 9 335 403.8 177 3556

特定の時間 (ミリ秒) 内に処理されたリクエストの割合
  50% 177
  66% 296
  75% 415
  80% 519
  90% 842
  95% 1141
  98% 1615
  99% 1966
 100% 3556 (最長要求)

PHPを使用してスクリプトを記述しています。さらにテストしたところ、PHP スクリプトから MySQL 接続部分をコメントすると、「失敗したリクエスト」が 0 になることもわかりました。どうしたの？この失敗率を下げるにはどうすればよいですか?

ありがとう、アレック

4

5 に答える 5

7

100 の同時リクエストが予想されますか? 30 秒で 10,000 件のリクエストを受信できると思いますか?

このベンチマークを実行できることは素晴らしいことですが、それが何を意味するのかを自問してください。受信するトラフィックの実際の量について考えてください。ベンチマークするための質問が本当に必要です:

  • 私のサイトには 3,000 人のユーザーがいると予想しています。
  • 使用量のピーク時には、そのうちの 500 件がページにアクセスすることになると予想しています
  • 通常の使用量は、1 分間に 3 つのリクエストです。3 * 500 / 60 = ~ 25 req/sec
  • 私のサイトは 25 リクエスト/秒を処​​理でき、応答性がありますか (リクエストあたり 200 ミリ秒未満)?

Web の上位数パーセントに属していない限り、実際のページで 100 の同時リクエストが表示されることはありません。そのレベルのトラフィックに合わせてサイトを調整しても意味がありません。これらの数値を達成するには、アーキテクチャ レベルで設計を妥協する必要があります (データベースの使用方法、キャッシュ方法など。したがって、データベースがオンになっているときの失敗の数です)。

スクリプトのプロファイリングのみを行う場合は、xdebugを使用して、コードが時間を費やしている場所を見つけます。

于 2009-01-28T16:08:35.907 に答える
1

失敗したリクエストを受け取るべきではありません。失敗した理由を確認するには、エラー ログを確認する必要があります。

最も可能性が高いのは、MySQL の接続が不足していることです。その場合は、サーバーを調整して、より多くの同時接続を許可することができます (その量のトラフィックが予想される場合)。

于 2009-01-28T12:25:50.690 に答える
1

xdebugを使用してコードをプロファイリングしてみてください。 xdebugは、画面上のエラーとスタック トレースも改善します。

次に、webgrindを使用してプロファイルを適切な形式で表示します。

于 2009-01-28T15:12:47.827 に答える
1

これは素晴らしい仕事だと思います。途中？基準をはるかに超えていると言えます。

問題の 1 つは、本番環境でのサーバーの負荷です。スクリプトはこのサーバーでリクエストを発行していますが、開発インスタンスの唯一のユーザーである場合、通常の本番負荷を処理しているときに本番サーバーにアクセスしたときに何が起こるかわかりません。

その場合、2 つの要求ソースが必要です。1 つは新しいアプリを表し、もう 1 つはリソースを競合する生産プロセス用です。

ベンチマーク ソフトウェアで同時ユーザー数を設定できますか? このテストは、1000 件のリクエストを次々に送信するだけですか? 複数のユーザーが同時にサーバーを叩く方が現実的かもしれません。

送信間隔をランダムにすることはできますか? それはあなたの実際の状況をよりよく表しているかもしれません。

スクリプトが使用するデータを変更できますか? それは非常にうまく使用される条件を表していますか?

それ以外は、おめでとうございます。とても丁寧に教えてくださっているようです。

于 2009-01-28T12:08:51.723 に答える
0

リクエストあたり約 200 ミリ秒は、ほとんどのユーザーにとってページが「高速」に見える一般的な数値です。

于 2009-01-28T12:20:45.023 に答える