profilowanie nodejs; co może "Nieznany" być

Question

Podczas profilowania programu nodejs, widzę, że 61% znaczników jest powodowanych przez "Nieznany" (patrz poniżej). Co to może być? Na co powinienem zwrócić uwagę?

gr,

Coen

Statistical profiling result from node, (14907 ticks, 9132 unaccounted, 0 excluded). 

[Unknown]: 
    ticks total nonlib name 
    9132 61.3% 

[Shared libraries]: 
    ticks total nonlib name 
    1067 7.2% 0.0% C:\Windows\SYSTEM32\ntdll.dll 
    55 0.4% 0.0% C:\Windows\system32\kernel32.dll 

[JavaScript]: 
    ticks total nonlib name 
    1381 9.3% 10.0% LazyCompile: *RowDataPacket.parse D:\MI\packet.js:9 
...... 

Answer 1

Używasz 64-bitowej wersji Node.JS do uruchomienia aplikacji i 32-bitowej wersji powłoki D8 do przetworzenia swojej v8.log. Użycie 32-bitowej wersji Node.JS z ia32 jako obiektem kompilacji dla powłoki D8 lub 64-bitowej wersji Node.JS z x64 jako celem kompilacji powłoki D8 powinno rozwiązać problem.

Answer 2

Czy ładuje wszystkie moduły, które zostały zbudowane zależności?

Zasadniczo słowo "Nieznane" oznacza "nierozliczone" (sprawdź więcej informacji na stronie tickprocessor.js). Na przykład GC będzie drukować komunikaty takie jak "scavenge, begin, ...", ale to nie jest rozpoznawane przez logreader.js.

Pomoże Ci dowiedzieć się, jakiej biblioteki profilowania używasz do analizy pliku v8.log.

Aktualizacja

Pakiet node-tick nie został zaktualizowany przez ponad rok i jest prawdopodobnie brakuje wiele ostatnich prof poleceń. Zamiast tego spróbuj użyć node-profiler. Jest tworzony przez jednego z opiekunów węzła. A jeśli chcesz uzyskać absolutnie najlepszy wynik, musisz go zbudować, używając node-gyp.

Aktualizacja

Mam analizowany wyjście v8.log przy użyciu najnowszych od node-profiler (najpóźniej na master, nie ostatni tag) i publikowane wyniki na http://pastebin.com/pdHDPjzE

Pozwól mi wskazać na kilka kluczowych wpisów, które pojawiają się w połowie długości:

[GC]: 
    ticks total nonlib name 
    2063 26.2% 

[Bottom up (heavy) profile] 
6578 83.4% c:\node\node.exe 
1812 27.5% LazyCompile: ~parse native json.js:55 
1811 99.9%  Function: ~<anonymous> C:\workspace\repositories\asyncnode_MySQL\lib\MySQL_DB.js:41 
736 11.2% Function: ~Buffer.toString buffer.js:392 

Tak więc 26,2% całego typu skryptu zostało wydane na śmieci lekcja. Która jest znacznie wyższa niż powinna być. Chociaż dobrze koreluje to z czasem spędzonym na Buffer.toString. Jeśli tworzonych jest wiele buforów, a następnie konwertowanych na łańcuchy, oba muszą być gc'd, gdy opuszczają zasięg.

Jestem także ciekawy, dlaczego tak dużo czasu spędzam w LazyCompile dla json.js. A może dlatego, aby json.js było konieczne w aplikacji węzła?

Aby pomóc Ci dostroić wydajność aplikacji, zamieszczam poniżej kilka linków, które zawierają dobre instrukcje dotyczące tego, co należy zrobić i czego szukać.

Nicea pokład slajdów z podstawami:
https://mkw.st/p/gdd11-berlin-v8-performance-tuning-tricks/#1

Bardziej zaawansowane przykłady technik optymalizacyjnych:
http://floitsch.blogspot.com/2012/03/optimizing-for-v8-introduction.html

Lepsze wykorzystanie zamknięć:
http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html

Teraz miarę dlaczego nie mógł osiągnąć tego samego wyniku.Jeśli zbudowałeś i użyłeś node-profiler i jego dostarczonego nprof z master i nadal nie działa, będę zakładać, że ma to coś wspólnego z byciem w systemie Windows. Pomyśl o zgłoszeniu błędu na GitHub i sprawdź, czy ci pomoże.

Answer 3

Spróbuj zbudować V8 z profilowania wsparcia na:

scons prof=on d8 

Upewnij się uruchomić node --prof z wersji odpowiadającej wersji v8

Następnie tools/linux-tick-processor path/to/v8.log powinien pokazać pełne informacje profilu.