Rendimiento y lagUn perfilador te dice adónde se fue el tiempo del tick. El informe intimida porque es un árbol de llamadas completo, pero solo hay que leerlo de una manera: de arriba abajo, siguiendo el porcentaje más grande.
Sacar un perfil que sirva
- Perfila mientras va mal
/spark profiler starty espera al problema. Un perfil de un servidor sano te dice qué hace un servidor sano, que no es lo que preguntabas. - Déjalo unos minutos
Treinta segundos pillan un pico; cinco minutos pillan un patrón. Para un problema intermitente, más largo es mejor.
- Páralo y abre el enlace
/spark profiler stopte da un visor web. No hace falta instalar nada para leerlo.
Las tres formas que vas a ver
| Forma | Significa |
|---|---|
| Un plugin arriba en el árbol | Ese plugin. Lee el nombre del método: suele decir qué estaba haciendo. |
| Ticado de entidades o de bloques dominando | Una granja, un almacén, o demasiado cargado. No es problema de plugins. |
| Tiempo repartido fino entre todo | Sencillamente estás al límite del plan. Este es el caso en el que un plan mayor es la respuesta honesta. |
Si el servidor está sano, algo tiene que ser igualmente lo más grande del árbol: eso es aritmética, no un error. Los porcentajes importan cuando el TPS está de verdad por debajo de 20. Optimizar la entrada más alta de un perfil sacado con 20 TPS es perseguir nada.
/spark health antes de perfilarEnseña TPS, duración del tick y memoria en una pantalla. Si la duración del tick va bien y la memoria está en el techo, tu problema es la recolección de basura y un perfil del tick no te lo va a enseñar.
Sobre Timings
Las guías antiguas te dicen que uses /timings. Paper se ha ido apartando de él en favor de spark, y en versiones recientes puede que el comando ni exista. Si una guía empieza por Timings, mira su fecha antes de seguir el resto.