5

私は Web アプリケーションに取り組んでいますが、必要な機能のほとんどを手に入れるところまで来ており、実行速度について心配し始めています。そのため、情報を探し回ったところ、CSS/JS の最小化、キャッシュ制御ヘッダーの設定、静的ファイルに別のドメインを使用すること、出力の圧縮など (および基本的なサーバー- memcached などのサイド テクニック)。しかし、私はすでにすべてを最適化しており、Web アプリがページを生成するのに実際にかかる時間、つまりキャッシュ ヒットのない純粋なサーバー側の処理時間に関心があるとしましょう。明らかに、その時間を短縮するための秘訣は、使用している言語と基盤となるライブラリによって異なりますが、目標とするのに妥当な数はどれくらいでしょうか? 比較のために、私は'

処理時間 (または、少なくとも私が書いたコード内で発生する時間の一部) を測定するために、少しコードを書き込んでみましたが、一般的に 50 ～ 150 ミリ秒の範囲の値が見られます。これはかなり高いようです。それを下げることにどれだけ集中すべきか、またはこのアプリへのアプローチ全体が遅すぎて、あきらめてもっと簡単なことを試してみるべきかどうかを知りたい. (Firebug の [ネット] タブに基づくと、同じコンピューター上のクライアントとサーバーの両方でテストしていることを考えると、私が測定していない処理の部分は通常 5 ミリ秒未満しか追加されません。)

参考までに、Werkzeug と SQLAlchemy/Elixir を使用して Python で作業しています。それらが最も効率的なテクノロジーではないことはわかっていますが、私が本当に関心を持っているのは、可能な限り高速ではなく、十分に高速であることだけです。

編集: 明確にするために、上記で引用した 50 ～ 150 ミリ秒は、HTML ページ自体の純粋なサーバー側の処理時間です。ユーザーから見たページの読み込みに実際にかかる時間は、CSS/JS/画像のアクセス時間のため、少なくとも 200 ミリ秒 (合計で 250 ～ 350 ミリ秒) 長くなります (ただし、キャッシングとExpiresヘッダー、スプライトなどの適切な使用。これは近い将来行う予定です)。その上に、ネットワークの待ち時間がさらに多くの時間を追加するため、クライアントの合計読み込み時間はおそらく 500 ミリ秒になります。

さらに良いことに、典型的な例として、Firebug の [Net] タブのスクリーンショットを示します Firebug からの読み込み時間 。

4

4 に答える 4

5

IMHO、サーバー側のクライアント側で50〜150ミリ秒は、ほとんどの状況で問題ありません。いくつかの非常に有名なウェブサイトの速度を測定するとき、私はめったに速いものを見ません。ほとんどの場合、それは約250ミリ秒であり、多くの場合それより長くなります。

さて、3点を強調したいと思います。

  1. すべてはコンテキストに依存します。ホームページや頻繁にアクセスされるページは、ロードに数秒かかると非常に無駄になります。一方、最適化に費用がかかる場合、Webサイトのほとんど使用されない部分には最大1秒かかることがあります。

  2. ユーザーの主な関心事は、彼らが望むことを迅速に達成することです。単一のページにアクセスするのにかかる時間ではなく、情報にアクセスしたり、目標を達成したりするのにかかる時間です。つまり、ユーザーが同じことを行うために3つのページに次々にアクセスする必要があり、各ページの読み込みに150ミリ秒かかるよりも、1つのページに250ミリ秒かかる方がよいということです。

  3. 知覚されるロード時間に注意してください。たとえば、StackOverflowWebサイトで使用されている興味深いトリックがあります。賛成/反対投票など、AJAXに基づく何かを行う場合、最初に効果を確認してから、サーバーにリクエストを送信します。たとえば、自分のメッセージに賛成票を投じてみてください。メッセージが賛成票を投じられていることを示し（矢印がオレンジ色になります）、 200ミリ秒後に矢印が灰色になり、エラーボックスが表示されます。したがって、賛成票の場合、リクエストの実行に費やされた実際のロード時間が100ミリ秒の場合、知覚されるロード時間（矢印がオレンジ色になります）は1ミリ秒です。

編集： 200ミリ秒でも問題ありません。ページが頻繁にアクセスされる場合、またはユーザーがページが高速であると期待している場合（たとえば、AJAX要求は高速であると期待されている場合） 、500ミリ秒はおそらく少し痛いでしょう。ちなみに、スクリーンショットでは、いくつかのCSSファイルと10個のPNG画像を使用していることがわかります。CSSを1つのファイルに結合し、CSSスプライトを使用することで、特にネットワーク遅延を処理する場合に、認識されるロード時間を短縮できる可能性があります。

于 2010-06-24T09:22:05.640 に答える
2

ユーザビリティに関する著名な講演者である Jakob Nielsen は、数日前にこれに関する記事 [1] を投稿しました。彼は、1 秒未満が適切であり、100 ミリ秒未満が最適であると提案しています。これは、ユーザー フローをもう少し中断するからです。

他のユーザーが指摘しているように、それはそのページのコンテキストに依存します。誰かがファイルをアップロードしている場合、遅延が予想されます。ユーザーがログインするのに 10 秒かかると、イライラし始める可能性があります。

[1] http://www.useit.com/alertbox/response-times.html

于 2010-06-24T09:38:19.840 に答える
1

Webサービスに対して一連のパフォーマンステストを作成して実行したときの古いJMeterの結果をいくつか調べました。それらのいくつかを以下に添付します。もちろん、それはリンゴ同士ではなく、少なくとも別のデータポイントです。

時間はミリ秒単位です。固有の遅延はそれぞれ15000ミリ秒と3000ミリ秒でしたLocation Req。携帯電話会社のLDAPサーバーへのクイックコールが含まれています。その他はかなり標準的で、主にデータベースの読み取り/書き込みです。Map ReqInvite

sampler_label    count    average    min    max
Data Blurp       2750     185        30     2528 
UserAuth         2750     255        41     2025
Get User Acc     820      148        29     2627
Update User Acc  4        243        41     2312
List Invitations 9630     345        47     3966
Invite           2750     591        102    4095
ListBuddies      5500     344        52     3901
Block Buddy      403      419        79     1835
Accept invite    2065     517        94     3043
Remove Buddy     296      411        83     1942
Location Req     2749     16963      15369  20517
Map Req          2747     3397       3116   5926

このソフトウェアは、本番VMと同じように調整された専用の適切な仮想マシンで実行されました。max結果は遅く、私の目標はサポートできる同時ユーザーの数を見つけることだったので、それを推進していました。

あなたの番号は絶対に大丈夫だと思います。ウェブサイトを遅く見せている他のすべてのものに関しては、そうでない場合は、YSlowを見てください。Firebugとうまく統合され、ページの読み込みを高速化する方法に関する優れた情報を提供します。

于 2010-06-24T09:19:36.583 に答える
0

ページの読み込み時間は 50 ～ 150 ミリ秒で十分です。この時点でさらに最適化する必要はありません。

実際、ページが 1 秒以内に読み込まれる限り、問題はありません。

コンバージョンの読み込み時間の影響について説明しているこの記事を参照してください(Amazon では 100 ミリ秒の増加 = 1%)。

于 2010-06-24T09:12:27.923 に答える