Unsere Anwendung hat ~ 10 Threads, die getrennte Aufgaben ausführen (keine Thread-Pools). Wir erleben keinen Deadlock, versuchen aber immer, die Latenzzeit zu verringern, um auf eine Anfrage zu antworten, so dass wir daran interessiert sind, zu ermitteln, welche Locks am meisten umstritten sind. jconsole zeigt an, wie oft Threads blockiert werden, und es ist nicht sehr oft, aber wir wollen immer noch wissen, welche Locks am meisten betroffen sind.
Da wir die Sun JVM verwenden, ist JLA von IBM nicht nützlich, und wir arbeiten nicht mit Solaris, sodass wir dTrace nicht verwenden können.
EDIT: Ich möchte diese Beobachtung in der Produktion machen, wo ein Profiler die App inakzeptabel verlangsamen würde. Dies ist ein Handelssystem, wenn wir langsam sind, verlieren wir Geld, also führen wir keine Profiler in der Produktion aus. Es ist auch ziemlich schwierig, den vielen Austausch zu simulieren, mit dem wir in einem Leistungstest sprechen.
Holen Sie sich einen guten Profiler wie YourKit . Es kann Ihnen sagen, wie viel Zeit damit verbracht wird, auf bestimmte Methoden und Objektmonitore zu warten und zu blockieren. Zum Beispiel:
alt text http://i25.tinypic.com/j8ocbm.jpg
In Bezug auf Ihren Kommentar zu Produktionsmetriken sind Sie ziemlich begrenzt in dem, was Sie sammeln können. Die meisten Informationen, die Sie erhalten, stammen aus dem ThreadMXBean Das kann Ihnen Metadaten über alle laufenden Threads geben. Es wird Ihnen jedoch keine Informationen über den Konflikt eines bestimmten Objektmonitors geben.
Ich möchte hier nicht in meinen Elfenbeinturm, aber ich glaube wirklich, dass es am besten ist, wenn Sie versuchen, Ihre Produktionsumgebung so nah wie möglich zu reproduzieren. Eine gewisse Zeit damit zu verbringen, sich jetzt einzurichten, wird sich in der Zukunft um ein Vielfaches auszahlen.
Selbst wenn Sie einen Profiler in einer simulierten, aber nicht ganz guten Umgebung ausführen, erhalten Sie wahrscheinlich gute Informationen.
Ted, ich habe Verständnis für Ihre Situation, aber wenn Leistung so wichtig ist, würde ich Ihnen empfehlen, in den sauren Apfel zu beißen und zu simulieren.
Es sollte nicht so schwer sein, wie Sie befürchten: Anstatt zu versuchen, Nachrichtenfluss von Ihrem Austausch zu generieren, warum nicht den eingehenden Fluss aufzeichnen und ihn erneut in der Simulation wiedergeben?
Ohne etwas Ähnliches werden Sie immer auf das Heisenberg-Problem stoßen: das System beeinflussen, das Sie messen.
Bei einem ähnlichen Problem in der Datenbank protokollieren wir eine Zeile kurz vor dem Anfordern und unmittelbar nach dem Erfassen einer Sperre. Wir melden uns auch nach der Freigabe. Wir verarbeiten diese Daten anschließend weiter, um die gesuchten Statistiken zu generieren.
EDIT: Auf einem entwickelten System könnte AspectJ eine gute Option sein, um die Protokolle zu generieren.
Tags und Links java multithreading
