Leistungstests auf Code-Ebene

Ich habe mir kürzlich die Leistung des ActivityPub-Plugins angesehen und über die besten Möglichkeiten nachgedacht, die Leistung für ein solches Projekt zuverlässig zu testen und nachzuweisen. Hier sind einige erste Hintergrundinformationen:

  • Das Plugin ist ein Open-Source-Projekt, an dem mehrere Parteien beteiligt sind (d. h. Discourse, dem das Plugin gehört, und Pavilion, das es derzeit entwickelt).
  • Verschiedene Parteien können unterschiedliche interne Leistungstestwerkzeuge/-systeme haben.
  • Multi-Parteien-Open-Source-Projekte profitieren von allgemein verfügbaren Methoden zum Testen und Nachweisen, dass etwas zuverlässig funktioniert oder in diesem Fall Leistung bringt.
  • Discourse (lobenswerterweise) achtet auf Leistung.

Bei Discourse glauben wir, dass Leistung ein Feature ist. Wir begrüßen Pull-Requests, die entweder die Client- oder Server-seitige Leistung verbessern.

Ein aktuelles Beispiel für die Verwendung von track_sql_queries finden Sie unter

Wenn Sie mit diesem Bereich vertraut sind, wissen Sie wahrscheinlich etwas wie

Faustregel: Unit-Tests brauchen Geschwindigkeit und Performance-Tests brauchen Zeit.

(Zitat aus diesem guten Erklärer)

Was auf den ersten Blick das Leistungstesten (über die Abfragezählung hinaus) etwas schwierig in eine RSpec-Suite (oder ähnliches) zu integrieren macht. Allerdings versuchen einige Leute es:

Ich bin neugierig, welche anderen praktischen Methoden, Vorschläge oder Ideen die Leute haben, um dem Discourse-Ökosystem allgemein verfügbare Leistungstests und Leistungsnachweise hinzuzufügen. Oder ob es Methoden oder Ansätze gibt, die ich hier nicht erwähnt habe. Ich würde die Worte „praktisch“ und „allgemein verfügbar“ dort betonen.

Ein Gedanke, der mir kommt, ist, dass man MiniProfiler in einem Spec verwenden könnte, d. h. etwas wie Rack::MiniProfiler.profile_singleton_method. Aber ich habe das weder ausprobiert noch weiß ich, ob das eine gute Idee wäre.

7 „Gefällt mir“

Meine allgemeine Empfehlung ist, Leistungstests in Specs zu vermeiden.

Wir haben einige Beispiele, in denen wir versuchen, N+1-Probleme in einer Spec zu überwachen, aber sie sind alle ziemlich fehleranfällig.

Es ist ein sehr, sehr schwieriges Problem ohne offensichtliche Lösung. Alle Lösungen haben Kompromisse, daher vermeiden wir dies im Allgemeinen und überwachen nur die Produktion auf diese Art von Problemen.

1 „Gefällt mir“