コードレベルのパフォーマンス テスト

開発
1

最近、ActivityPubプラグインのパフォーマンスを調べており、このようなプロジェクトのパフォーマンスを確実にテストし、証明するための最善の方法を検討しています。以下に、初期のコンテキストをいくつか示します。

  • このプラグインは、複数の関係者が関与するオープンソースプロジェクトです（つまり、プラグインを所有するDiscourseと、現在開発中のPavilion）。
  • 関係者ごとに、内部のパフォーマンステストツール/システムが異なる場合があります。
  • マルチパーティのオープンソースプロジェクトは、何かが確実に機能している、またはこの場合はパフォーマンスを発揮していることをテストし、証明するための一般的に利用可能な方法から恩恵を受けます。
  • Discourseは（称賛に値するほど）パフォーマンスを重視しています。

Discourseでは、パフォーマンスは機能であると信じています。クライアントまたはサーバー側のパフォーマンスを改善するプルリクエストを歓迎します。

  • 現在、Discourseでサーバーサイドのパフォーマンスをテスト/証明するための一般的に利用可能な唯一の方法（私が知る限り）はtrack_sql_queriesであり、これは通常（ただし排他的ではありません）リクエストテストで使用されます。
  • クエリ数はパフォーマンスの指標の1つですが、それだけではありません（クエリによっては他のクエリよりも大きいものもあります）。

track_sql_queriesの使用例については、最近の例を参照してください。

この分野に精通している方なら、おそらく次のようなことをご存知でしょう。

一般的な経験則として、単体テストには速度が必要であり、パフォーマンステストには時間が必要である。

（この適切な解説より引用）

これは、一見すると、パフォーマンスのテスト（クエリ数のカウント以外）をrspec（または類似の）スイートに統合することをやや困難にします。とはいえ、試みる人もいます。

この分野に詳しい方で、Discourseエコシステムに、より一般的に利用可能なパフォーマンステストやパフォーマンス証明を追加するための、他の実践的な方法、提案、またはアイデアをお持ちの方はいらっしゃいますか。あるいは、ここで言及していない方法やアプローチはありますか。「実践的」と「一般的に利用可能」という言葉を強調しておきます。

考えられることの1つは、specでMiniProfilerを使用できる可能性があるということです。たとえば、Rack::MiniProfiler.profile_singleton_methodのようなものです。しかし、私はそれを試したこともなく、それが良い考えかどうかを知りません。

「いいね！」 7
2

私の一般的な推奨事項は、スペックでのパフォーマンステストを避けることです。

スペックでN+1を監視しようとする例がいくつかありますが、それらはすべて非常に壊れやすい傾向があります。

これは非常に困難な問題であり、明白な解決策はありません。すべての解決策にはトレードオフが伴うため、一般的にはこれを避け、このような問題は本番環境で監視しています。

「いいね！」 1