He estado analizando el rendimiento del plugin ActivityPub recientemente y considerando las mejores maneras de probar y demostrar de manera confiable el rendimiento para el propósito de dicho proyecto. Aquí hay algunas piezas iniciales de contexto:
- El plugin es un proyecto de código abierto con múltiples partes involucradas (es decir, Discourse, que posee el plugin, y Pavilion, que lo está desarrollando actualmente).
- Diferentes partes pueden tener diferentes herramientas/sistemas internos de prueba de rendimiento.
- Los proyectos de código abierto multipartitos se benefician de métodos comúnmente disponibles para probar y demostrar que algo funciona, o en este caso, rinde, de manera confiable.
- Discourse (loablemente) se preocupa por el rendimiento.
En Discourse creemos que el rendimiento es una característica. Damos la bienvenida a las solicitudes de extracción que mejoran el rendimiento del lado del cliente o del servidor.
- Actualmente, el único método comúnmente disponible para probar/demostrar el rendimiento del lado del servidor en Discourse (que conozco) es
track_sql_queries(discourse/spec/support/helpers.rb at 467e1a1bddb8266e4ab1165fbba71745d4f9c269 · discourse/discourse · GitHub), que se usa típicamente (pero no exclusivamente) en pruebas de solicitud. - Si bien el recuento de consultas es un indicador del rendimiento, no es el único (algunas consultas son más grandes que otras).
Para un ejemplo reciente del uso de track_sql_queries, consulta
Si estás familiarizado con esta área, probablemente sepas algo como
La regla general es que las pruebas unitarias necesitan velocidad y las pruebas de rendimiento necesitan tiempo.
(cita de este decente explicador)
Lo que, a primera vista, puede hacer que las pruebas de rendimiento (más allá del recuento de consultas) sean algo difíciles de integrar en una suite rspec (o similar). Dicho esto, algunas personas lo intentan
Tengo curiosidad por saber qué otros métodos, sugerencias o ideas prácticas tienen las personas para agregar pruebas de rendimiento y demostraciones de rendimiento más comúnmente disponibles al ecosistema de Discourse. O si hay métodos o enfoques que no he mencionado aquí. Enfatizaría las palabras “prácticas” y “comúnmente disponibles” allí.
Un pensamiento que se me ocurre es que podría ser posible usar MiniProfiler en una especificación, es decir, algo como Rack::MiniProfiler.profile_singleton_method. Pero no lo he probado ni sé si sería una buena idea.