Tests de performance au niveau du code

Dev
1

J’ai récemment examiné les performances du plugin ActivityPub et j’ai réfléchi aux meilleures façons de tester et de prouver de manière fiable les performances dans le cadre d’un tel projet. Voici quelques éléments de contexte initiaux :

  • Le plugin est un projet open source impliquant plusieurs parties (c’est-à-dire Discourse, qui possède le plugin, et Pavilion, qui le développe actuellement).

  • Différentes parties peuvent avoir leurs propres outils / systèmes de test de performance internes.

  • Les projets open source multipartites bénéficient de méthodes couramment disponibles pour tester et prouver que quelque chose fonctionne, ou dans ce cas, performe, de manière fiable.

  • Discourse (louablement) se soucie des performances.

  • Actuellement, la seule méthode couramment disponible pour tester / prouver les performances côté serveur dans Discourse (à ma connaissance) est track_sql_queries (lien), qui est généralement (mais pas exclusivement) utilisée dans les tests de requêtes.

  • Bien que le nombre de requêtes soit un indicateur de performance, ce n’est pas le seul (certaines requêtes sont plus importantes que d’autres).

Pour un exemple récent d’utilisation de track_sql_queries, voir

Si vous êtes familier avec ce domaine, vous savez probablement quelque chose comme

La règle générale est que les tests unitaires ont besoin de vitesse et les tests de performance ont besoin de temps.

(citation de cette bonne explication)

Ce qui, à première vue, peut rendre les tests de performance (au-delà du comptage des requêtes) quelque peu difficiles à intégrer dans une suite rspec (ou similaire). Cela dit, certains essaient

Je suis curieux de connaître d’autres méthodes, suggestions ou idées pratiques que les gens pourraient avoir pour ajouter des tests de performance et des preuves de performance plus couramment disponibles à l’écosystème Discourse. Ou s’il existe des méthodes ou approches que je n’ai pas mentionnées ici. J’insisterais sur les mots “pratique” et “couramment disponible”.

Une idée qui me vient à l’esprit est qu’il pourrait être possible d’utiliser MiniProfiler dans un spec, c’est-à-dire quelque chose comme Rack::MiniProfiler.profile_singleton_method. Mais je n’ai ni essayé cela, ni je ne sais si ce serait une bonne idée.

7 « J'aime »
2

Ma recommandation générale est d’éviter les tests de performance dans les specs.

Nous avons quelques exemples où nous essayons de surveiller les N+1 dans une spec, mais ils ont tous tendance à être assez fragiles.

C’est un problème très, très difficile sans solution évidente, toutes les solutions comportent des compromis, nous évitons donc généralement cela et nous nous contentons de surveiller la production pour ce genre de choses.

1 « J'aime »