Jaki profiler polecacie? Do sprawdzenia wydajności?

1

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.

2

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

2

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ć.

2

Rzadko używam takich dedykowanych narzędzi, przeważnie wystarczają mi proste akcje typu:

  1. 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"
  2. podpięcie się pod proces JVM narzędziem typu strace i oglądanie tego co się dzieje na poziomie wywołań systemowych
  3. 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)
2

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.

1
  1. może głupie, ale działa praktycznie wszędzie (jak vi), czyli nie takie głupie :)
  2. 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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1