performance - 動的に生成される Web ページの作成速度はどれくらいですか?

Question

内部ユーザーと一般ユーザーの両方にサービスを提供するデータ駆動型の Web ベースのアプリケーションが多数あり、ユーザーの満足度とスケーラビリティを維持するためにページが作成される速度 (ミリ秒単位) を測定したいと考えています。

では、高速なサイトを維持するには、どのくらいの速さでページが作成されるのでしょうか?

サイトは ASP クラシックで開発されており、XSLT を使用してレンダリングする XML レコードセットを生成する SQL Server バックエンドを使用しています。ページの複雑さに応じて、最も効率的な手法ではなく、ページの作成に 7 ミリ秒から 120 ミリ秒かかります (つまり、コードの最初の行と「Response.Write」の間のタイマー間隔)。ページが遅いのは、データベースがより大きく複雑なクエリを実行しているためです。すべての ASP クラシックを ASP.NET に書き直したとしても、ページ全体のレンダリング速度が大幅に向上することはありません。

Jeff が、SO を最速のサイトにしたいと言っているのをよく耳にします。彼のブログでは、コードとデータベースの最適化について議論していますが、コードの最適化にはどこまで行かなければなりませんか? String + String の代わりに StringBuffer を使用してミリ秒を削ることは、私の時間を有効に活用していますか?

【説明】

「このページは作成に時間がかかりすぎている」と思うのはどの時点ですか。20 ミリ秒以上ですか、200 ミリ秒以上ですか、それともページの作成に 1 秒以上かかっても問題ありませんか? あなたの「目標タイム」は？

Answer 1

これは、オーディエンスとターゲットに完全に依存します。ターゲットの「onload」イベントが4秒未満のアプリと、サーバーでの時間が1ミリ秒未満であると予想されるアプリに取り組んできました。どちらの方向にも進むことができますが、サーバー側レベルで実行するパフォーマンスの最適化は、ネットワークパフォーマンス、依然としてWebの主要なボトルネック、および知覚的なロード時間の両方によって矮小化される可能性があることに注意する必要があります。

Yahooには、一般的なWebサイトのパフォーマンス、特に知覚的な負荷領域に関する優れたガイドラインがいくつかあります。

うまくいけば、あなたはすでにあなたができることをキャッシュし、Response.Writesの大規模なチェーンを回避するような小さなことをするのに十分賢いです...

Answer 2

ユーザーは、データの準備速度を気にせず、ページの実際の読み込み時間だけを気にします。

レンダリングに多くのオーバーヘッドがある場合、ユーザーはサイトの速度が低下することを経験します。従来のASPに関しては、文字列の連結は非常に悪い習慣と見なされます。これは、サーバーに負担がかかり始める重要な文字列の長さに達すると、文字列の連結が非常に遅くなるためです。

配列（jscript）または.NET StringBufferを使用すると、レンダリング時間を大幅に改善できます。サーバーがより多くのトラフィックを処理できるようにする不必要なCPU使用率をアンロードするだけでなく、この種の明らかな最適化は非常に価値があると思います。

Answer 3

このトピックに関する非常に興味深いスクリーンキャストは、ここにあります：リンクテキスト。

Railsの人によって作成されていますが、他のフレームワークにも完全に適用できます。

Answer 4

1 つのことを変更するだけで数ミリ秒を削ることができる場合は、それを試してみてください。

データベース リクエストのキャッシュについても調べてみるとよいでしょう。

Answer 5

サーバーの応答時間に対するユーザーの満足度に影響を与える要因の 1 つは、ユーザーが新しいページを要求する頻度です。ユーザーが読むのに時間がかかる大量の情報を含むページを (たとえば) 表示している場合は、「レンダリング」時間が長くても問題ありません。対照的に、ユーザーがページをすばやく移動している場合、ほぼ瞬時の応答が必要になります。

たとえば、ニュース サイトを閲覧している場合、次のページを読むのに 30 秒かかるため、次のページに 1 ～ 2 秒かかっても問題ないでしょう。

一方、インタラクティブ マップを閲覧している場合は、応答を 1 秒未満にする必要があります。