3

理想的にはプログラムフローに沿って（通常のスレッド呼び出しスタックではなく）、要求ごとのプロファイリング統計をサポートするプロファイラーを探しています。つまり、基本的に、プロファイラーの呼び出しスタック+単一の要求ごとの順次呼び出しビューは、次のようになります。

doGet                 100ms
+ doFilter             95ms
  + doFilter2          90ms
    + validateValues   20ms
    + calculateX       40ms
      + calc1          10ms
      + calc2          30ms
    + renderResponse   30ms

どのクラス/メソッドがプロファイリングされるかは、何らかの方法で構成されます。各メソッド呼び出しを処理するトレースプロファイラーの場合、これはもちろん使用できません。

私はdynaTraceを知っており、使用しています。その「PurePath」機能（http://www.dynatrace.com/en/architecture-tame-complexity-with-purepath.aspx）はこれをサポートしていますが、小規模なプロジェクトで使用でき、初期投資とセットアップが少なくて済みます。

「クラシック」プロファイラー（YourKitなど）はこれをサポートしていますか？私はこの機能を見落としていましたか？

補遺：背景を提供する：主な目標は、実稼働中のシステムの監視と分析のための統計を取得することです。何よりもまず、リクエストにかかる時間のライブ統計を取得し、応答時間が長くなった場合に特定の（タイプの）リクエストのデータを取得することです（JETM + xを考えてください）。

リクエストごとのプロファイリング統計により、一部のリクエストだけが遅い理由を詳細に分析できます。たとえば、リクエストの10％が平均の10倍の時間がかかる場合などです。集計された統計では、これを解決するのは非常に困難です。

プログラムフローに沿って呼び出しをレンダリングするプロファイリング統計についても同じことが言えます。これは、リクエストのどこに問題があるかを簡単に特定できるためです。たとえば、メソッドが10個のDBクエリを実行すると、各呼び出しは10個だけでなく単一の呼び出しとして表示されます。集約された呼び出し。

理想的には、測定ポイントは実行時に構成および有効化/無効化されます。

4

3 に答える 3

1

選択的な測定を行うためにbtraceを試すことができます。これは、サポートされているプラ​​ットフォーム、Solaris、BSD、OS X を使用している場合にも使用できる dtrace にいくぶん似ています。

于 2011-06-01T07:50:08.987 に答える
1

アプリケーションがミリ秒単位でタイミングを計っている場合は、要約してファイルに書き込むことができる TreeMap をステージングする時間のマップを持つことができます。これは最も柔軟で、ミリ秒単位のタイミングに適しています。

マイクロ秒単位のタイミングの場合、各ステージの列挙値を用意し、そのステージングに到達した時点の現在の時刻 (System.nanoTime()) を ThreadLocal 配列に記録します。(オブジェクト割り当てなし) リクエストが終了したら、タイミング デルタをファイル (CSV 形式など) に書き込みます。

于 2011-05-31T08:09:25.797 に答える
1

私のアプローチはピーターのアプローチに似ていますが、スレッドローカルを使用してオンラインで計算する代わりに、実行が興味深い段階に達したときにログ ファイルに書き込みます。また、AspectJ を使用してログ行を生成しました。これは、残りのソース コードを変更することなく、気まぐれにログ行を追加/削除するのに非常に便利であることがわかりました。

于 2011-05-31T08:16:42.523 に答える