Czesc,
Chciałem ostatnio sprawdzić dlaczego pewne flow w aplikacji strasznie wolno działa. Próbowałem użyć do tego visualVM, ale niestety na 10 prób tylko raz udało mi się uzyskać jakiekolwiek wyniki, generalnie strasznie zamułał kompa i apkę. Używałem też xrebela, ale nie nazwałbym tego toola profilerem. Macie coś godnego polecenia z własnego dośwadczenia? Z profilera zamierzam korzystać lokalnie także nie potrzebuję opcji remote.
https://github.com/jvm-profiling-tools/async-profiler
Problem jest taki ze wątki które czekają na IO nie będą zliczane :) Jak masz full nieblokujący stack to dziala iidealnie, jak uzywasz np tomcata to musisz brac na to porprawke
Moze to Ci pomoze? https://medium.com/netflix-techblog/netflix-flamescope-a57ca19d47bb
Jeszcze do posluchania:
I do poczytania: https://jrebel.com/rebellabs/java-profiling-from-the-ground-up-by-nitsan-wakart/
http://psy-lob-saw.blogspot.com/
W skrocie mozesz sie pobawic Honest-profilerem,
Używam najczęściej visualvm, bo jest zwykle pod ręką. Profilowanie (zależy jeszcze jaki rodzaj) zawsze trochę przydusza aplikację, więc trzeba mieć zapas mocy.
Z alternatyw to polecam JProfiler, jest komercyjny, ale chyba można dostać free trial.
Łatwy w użyciu i raczej bezproblemowy, jak się w nim ogarniesz to potem w visualvm też będziesz wiedział co robić.
Rzadko używam takich dedykowanych narzędzi, przeważnie wystarczają mi proste akcje typu:
- próbkowanie stosu - kilka razy zrzucam thread dumpa i buduję jakieś zestawienie: <stack#1, 10 razy>, <stack#2, 5 razy>, ... itd. Odsiewam od tego "systemowe stacki" i patrzę w którym miejscu aplikacja najczęściej "wisi"
- podpięcie się pod proces JVM narzędziem typu strace i oglądanie tego co się dzieje na poziomie wywołań systemowych
- dodanie logowania czasów wykonania operacji (+ logowanie Thread.currentThread().getStackTrace(), żeby jakoś zawęzić ścieżki kodu, po których trafiam w problematyczne miejsce - o ile jest współdzielone przez różne flow)
Co do tych metod:
ad 1. Próbkowanie - jstack, kill -3 - faktycznie łatwo można znaleźć jesli aplikacaja wisi, ale jak robimy kilka takich próbkowań i wyciągamy wnioski to jest to po prostu bieda wersja CPU samplingu - nie polecam, chyba, że sie inaczej nie da (bo jestesmy na zapyziałym serwerze u germańskiego oprawcy i nic tam innego nie zadziała).
ad. 3.Nie polecam, ręczne logowanie, dużo pracy, bardzo często logi wstawiamy w zupełnie miejsce niż trzeba (bo intuicja to bura suka), a do tego interpretowanie wyników tych opóżnień czsowych w przypadku programu wielowątkowego jest bardzo wątpliwe, zrzucanie stack trace do logów wa duży wpływ na pomiary. Dzięki tej metodzie kiedyś przez ileś miesięcy naprawialiśmy wydajność zupełnie nie tam gdzie trzeba.
- może głupie, ale działa praktycznie wszędzie (jak vi), czyli nie takie głupie :)
- Sprawdziło mi się przy diagnozowaniu "race condition" w systemie low-latency (podpięcie debuggera i ustawienie breakpointa trwało dłużej niż czas przewidziany na obsłużenie requestu - timeouty na request rzędu 30ms), ale to osobna straszliwa historia, gdzie ratunkiem była dekompilacja klas 3rd party, dodanie owego logowania, kompilacja i podmiana wersji klasy.