Al perfilar un progtwig nodejs, veo que el 61% de los tics son causados por ‘Desconocido’ (ver más abajo). ¿Qué puede ser esto? ¿Que debería buscar?
gramo,
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 ...... Está utilizando una versión de 64 bits de Node.JS para ejecutar su aplicación y una comstackción de 32 bits del shell d8 para procesar su v8.log . Usar una versión de Node.JS de 32 bits con ia32 como objective de comstackción para el shell d8 o una versión de Node.JS de 64 bits con x64 como el objective de comstackción del shell d8 debería resolver su problema.
¿Estás cargando algún módulo que haya construido dependencias?
Básicamente, por “Desconocido” significa “no contabilizado” (consulte tickprocessor.js para obtener más información). Por ejemplo, el GC imprimirá mensajes como “scavenge, begin, …” pero eso no es reconocido por logreader.js .
Sería útil saber qué biblioteca de perfiles está utilizando para analizar el archivo v8.log .
Actualizar
El paquete node-tick no se ha actualizado durante más de un año y es probable que falten muchos comandos recientes de prof . Trate de usar node-profiler en su lugar. Es creado por uno de los mantenedores del nodo. Y si desea obtener el mejor resultado absoluto, deberá comstackrlo utilizando node-gyp .
Actualizar
He analizado la salida de v8.log usando lo último de node-profiler (lo último en master , no la etiqueta más reciente) y publiqué los resultados en http://pastebin.com/pdHDPjzE
Permítanme señalar un par de entradas clave que aparecen aproximadamente a la mitad:
[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: ~ C:\workspace\repositories\asyncnode_MySQL\lib\MySQL_DB.js:41 736 11.2% Function: ~Buffer.toString buffer.js:392
Así que el 26.2% de todo el tipo de script se gastó en la recolección de basura. Que es mucho más alto de lo que debería ser. Aunque se correlaciona bien con cuánto tiempo se gasta en Buffer.toString . Si se crean tantos búfers y luego se convierten en cadenas, ambos tendrían que ser gc’d cuando dejan el scope.
También tengo curiosidad por saber por qué se gasta tanto tiempo en LazyCompile para json.js O más aún, ¿por qué json.js sería incluso necesario en una aplicación de nodo?
Para ayudarlo a optimizar el rendimiento de su aplicación, incluyo algunos enlaces a continuación que brindan buenas instrucciones sobre qué hacer y buscar.
Bonita cubierta deslizante con lo básico:
https://mkw.st/p/gdd11-berlin-v8-performance-tuning-tricks/#1
Ejemplos más avanzados de técnicas de optimización:
http://floitsch.blogspot.com/2012/03/optimizing-for-v8-introduction.html
Mejor uso de los cierres:
http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html
Ahora en cuanto a por qué no pudo lograr el mismo resultado. Si usted construyó y usó node-profiler y su nprof proporcionado de master y aún no funciona, asumiré que tiene algo que ver con estar en Windows. Piensa en presentar un error en GitHub y ver si te ayuda.
Intente construir v8 con soporte de perfiles en:
scons prof=on d8
Asegúrese de ejecutar node --prof con la versión correspondiente a la versión de v8
Luego las tools/linux-tick-processor path/to/v8.log deberían mostrarle la información completa del perfil.