API 呼び出しが非常に遅いという問題があり、Xhprof (デフォルト GUI とコールグラフ) を使用して原因を突き止めたいと考えています。このデータをどのように分析する必要がありますか?
最適化する必要があるコード内の場所、特に最もコストのかかるボトルネックを見つけるためのアプローチは何ですか?
1 に答える
1
これらすべての列のうち、「IWall%」と呼ばれる列 5に注目してsendください。doRequestreadfgets
つまり、100 個のスタック サンプルを取得した場合、これらのルーチンのそれぞれが 72 個のサンプルに含まれ、ギブまたはテイクし、それらが一緒に表示されるのではないかと思います。(グラフにもそれが表示されるはずです。)
全体で 23 秒かかるので、約 17 秒が単に読むだけに費やされることになります。その 17 秒を短縮できる唯一の方法は、読み取りの一部が不要であることがわかった場合です。あなたはできる？
残りの 28% (6 秒) はどうでしょうか。まず、それは価値がありますか？これをゼロ (合計 17 秒、それはできません) に減らすことができたとしても、スピードアップ係数は 1/(1-0.28) = 1.39、つまり 39% になります。半分 (合計 20 秒) 減らすことができれば、1/(1-0.14) = 1.16、つまり 16% になります。20 秒対 23 秒。苦労する価値があるかどうかを判断するのはあなた次第です。
そうだと判断した場合は、ランダムな一時停止方法をお勧めします。ノイズが殺到しないためです。どのルーチンだけでなく、どのコード行と、なぜそれらが実行されているのかを伝えることで、問題の核心に迫ることができます。(絶対に必要な場合は置き換えることができないため、理由が最も重要です。プロファイラーでは、それ以外の方法がないため、必要であると想定する傾向があります。)
約 14% の時間をかけて何かを探しているので、平均して 2/0.14 = 14 サンプルを調べて 2 回見る必要があり、それが何であるかがわかります。これらのサンプルの約 14 * 0.72 = 10 がfgets(およびそのすべての呼び出し元) に到達することに注意してください。したがって、それらを無視するか、それらを使用してすべての I/O が本当に必要であることを確認できます。（たとえば、その方が簡単だったなどのあいまいな理由で、物事を2回読んでいる可能性はありますか？私はそれを見ました。）
于 2015-09-05T14:27:10.490 に答える