18

サーバー側コードの効率を把握しようとしています。

を使用microtime(true)して速度を測定すると、スクリプトの実行にかかった時間を計算できます。

.3から.5秒の平均速度を取得しています。これらのスクリプトは、多数のデータベース クエリを実行して、さまざまな値をユーザーに返します。

Web サイトでオンラインで実行される PHP スクリプトの効率的な実行時間はどれくらいですか?

何が行われているかに正確に依存することはわかっていますが、これをデータベースから読み取り、ユーザーに値を返す標準スクリプトと考えてください。Google を見ると、彼らがインターネットを.15数秒で検索しているのを見て、自分のスクリプトがくだらないと感じます。

4

13 に答える 13

9

YouTube の目標ページ レンダリング時間は 100 ミリ秒未満です (ビデオはこちら@7:00)。

あなたのボトルネックはおそらくDBクエリです - 使ってみてください

EXPLAIN select * from x...

クエリを高速化するインデックスを追加できるかどうかを確認します。

上記のリンクを編集してください。High Scalability は、そのビデオを主要なソースとして使用する YouTube の機能を実行したので、興味があるかもしれません: http://highscalability.com/youtube-architecture

于 2010-03-14T20:11:29.183 に答える
3

それはより速くする必要がありますか、そしてその理由は何ですか?

答えが「はい、要件リストに載っているため」または「貴重なサーバー リソースを必要とするため」の場合は、SQL クエリの最適化を試みてください。インデックスを追加する必要があるかもしれません...

それ以外の場合は、次のタスクに進む必要があると思います。まず、それは機能し、2 番目に約 0.3 ～ 0.5 秒です。これは、人間と機械にとって十分に高速である必要があります。

于 2010-03-15T08:42:11.940 に答える
2

うーん...ここでは絶対値がかなり公平かどうかわかりません。それは本当にハードウェアに依存します...ローカルで開発するとき、私の開発者マシンは実際のサーバーよりも5〜10倍遅く実行されます。したがって、絶対値を取る場合、「許容範囲」はハードウェアによって異なります。

一般的には、100 ミリ秒未満に保つようにしています。サーバーのロード時間が長い場合は、実行を追跡して何が問題なのかを突き止めます。ほとんどの場合、データベース (したがってクエリ) がボトルネックになっていると言わざるを得ません。そのための実際の作業は本当に重要です。

于 2010-03-14T20:30:33.690 に答える
2

PHP を使用すると、ほとんどの Web サイトが非常に高速に生成されるため、最大の遅延は、表示する画像などのすべてのサブリクエストを含むページのレンダリングです。
しかし、訪問者のインターネット接続の速度と品質、コンピューターとソフトウェアも重要な要素です。

寛大に言うと、PHP が Web ページの合計読み込み時間とレンダリング時間の 20% を占めるとしましょう。
繰り返しますが、このパーセンテージが非常に概算であることは承知していますが、より具体的な例です。

ページの平均読み込み時間は約 3 秒です。(これは多すぎます) 高品質の Web サイトは完全に読み込まれるまでに約 1 秒かかるため、PHP は出力を生成するのに 200 ミリ秒 (1 秒の 20%) かかります。そのため、php は「平均的な」Web サイトで最大 600 ミリ秒かかる可能性があります。

Note: The PHP execution time can be improved by changing your hoster, or by improving your source code.

于 2010-03-14T20:10:04.900 に答える
1

本当に、それはすべて相対的です。PHPを使用している他のサイトと同等の時間を得ることを期待しないでください。PHPは、ページを読み込むたびにすべてを最初から読み込む必要があることを忘れないでください。

本当にあなたは、Apache abを使用してサイトをテストするなど、負荷がかかった状態でサイトがどの程度うまく機能するかを確認したいと考えています。あなたのサイトがあなたが期待できる最高のトラフィックレベルを処理できるなら、あなたはもうそれを最適化する必要はありません。ユーザーは、ページが.75秒で読み込まれるのか.25秒で読み込まれるのかを判断できなくなります。

microtime自体を呼び出すと、オペレーティングシステム（コンテキストスイッチ）を呼び出す必要があるため、ページの読み込みに時間がかかることを忘れないでください。ページを最適化して小さくし、ネットワークをより速く通過し、クライアントで1回だけレンダリングする方が、より価値がある場合があります。

于 2010-03-14T20:51:37.840 に答える
1

10倍少なくても大丈夫だと思います。ただし、クエリの数は問題ではありません。それらは 20 個あり、すべて 0.005 秒間実行されます。重要なのは量ではなく、質です。コードをプロファイリングして、最も遅い部分を特定します。さらにマイクロタイム ステートメントを追加し、最も遅い部分を見つけて最適化します。

mysql をクエリするための独自の関数がある場合、そこにマイクロタイムのものを配置すると非常に便利です。

于 2010-03-14T20:11:16.503 に答える
1

述べたように依存しますが、さらにこれを考慮してください: 1 秒の実行時間で、(理想的な条件下で) 1 つの CPU を備えたサーバー マシンで 1 秒あたり 1 つの要求のみを処理でき、その上で他に何も起こっていません。機械。毎秒 1 件を超えるリクエストが着信すると、キューが長くなり、サーバーが完全に実行され、着信リクエストの処理にさらに時間がかかります。リクエストが少ない場合でも、CPU 使用率に注意を払う必要があります。以前からサーバーの負荷が高かった場合は、注意が必要な問題が発生している可能性があります。

キャパシティ要件の分析に使用できる数学的方法 (待ち行列理論) があります。詳細については、たとえば PDQ ( http://www.perfdynamics.com/Tools/PDQ.html ) を参照してください。

したがって、Google との比較は公平ではないかもしれません。なぜなら、Google には大量の受信リクエストが必要であり、実行時間が 3 倍長くなるため、既存の数倍のサーバーが必要になるからです...

于 2010-03-14T20:20:39.650 に答える
1

ウィキペディアの編集者として、ページの読み込み開始が約 5 秒から 10 秒を超えるまで、苦情は見られないことに気付きました。もちろん、このような遅さを報告するメカニズムは、ほとんどのユーザーにはわかりません。

旅行ウェブサイトのユーザーである私にとっては、「リクエストを受け取りました。現在処理中です。最大X秒かかる場合があります」という中間画面に十分に満足しています。

于 2010-03-14T20:56:42.697 に答える
1

もちろん、これは非常に主観的なものであり、サイトなどによって異なります。

ただし、ページが約 100 ミリ秒より長くかかり始めると、それはユーザーにとって顕著な遅延であり、「長すぎる」可能性があると言えます。それは、これが瞬時にロードされることが合理的に期待できるページである場合です。ページが検索ページで、大規模なデータベースで全文検索を行う場合、状況はもちろん異なります。

于 2010-03-14T19:48:41.433 に答える
1

200 ミリ秒未満を目指します。

人々は、200 ミリ秒を超える音に対してますます忍耐力を失い始めています。

于 2010-03-14T20:33:04.780 に答える
0

  • 同様のページランキングを維持していない限り、スクリプトをGoogleと比較しません..など.

  • 検索がデータベースから値を取得するだけの場合、アプリケーションをプロファイリングしてボトルネックを排除することで速度がいくらか向上する可能性があります (ページ上のスクリプト、大きな画像、大きなテーブル、データベース インデックスなど)。

于 2010-03-15T07:49:32.773 に答える