0

サーバー上にアプリケーションの一部があり、できるだけ早く返さなければなりませんが、現在は 0.5 秒から 1.8 秒かかりますが、これは計算の一部ではありません。これが意味することは、(マイクロタイムを使用して) プロセスの各部分の時間を計り、mysql の呼び出しと計算にかかる時間は毎回 0.2 秒未満ですが、戻って印刷すると 1 秒が追加されます。現在、これは容認できないほど遅いため、これをできるだけ速くするにはどうすればよいですか?

私が考えることができる2つの可能性があります.データは関数内に構築され、大きな配列が値として返されるため、返すのではなく単純に印刷する方が速いかもしれません. 2 つ目は、php の印刷バッファーに問題があると思います。印刷するテキストをより小さなチャンクに分割すると、各チャンクがすぐに印刷されます (~0.00002 秒) が表示されますが、印刷バッファーがいっぱいになったと思われる場所である約 0.5 ~ 1.5 秒のすべての余分な時間がかかります。たくさんの余分な仕事をします。これを修正する方法はありますか?

いくつかの詳細: 印刷されているテキストのサイズは約 150Kb です。flush や ob_ 関数は使用していませんが、それらを使って実験を行いましたが、違いはないようで、memcached は使用していません。echo は関数呼び出しではなくステートメントであるため、 print よりも高速であることは理解していますが、これによりどの程度の違いが生じるでしょうか? print は印刷するテキストを返すため、テキストが大きいほど印刷に時間がかかりますか?

4

1 に答える 1

2

ただし、戻って印刷すると、さらに秒が追加されます

コメントによると、これは非常に奇妙に思えます。アプリケーションの性質を考えると、私の考えは次のとおりです。

データは関数内に構築され、大きな配列が値として返されます

なぜこのような出力を延期するのですか? 大きな配列は、PHP の大きなパフォーマンスの問題です (NB Dan Lee: 数値と連想)。しかし、ヒットは要素の追加/個々の要素の参照にあります-配列を移動することは問題ではありません。

データを先に出力バッファに送信しないのはなぜですか?

印刷バッファがいっぱいになったようです

非常にありそうもない。

ob_start と flush は使用しません

次に、gz ハンドラーを優先して実行します。

于 2012-06-15T09:49:53.790 に答える