継続的なベンチマークとは何ですか?

継続的なベンチマーキングは、チームの一員が頻繁に彼らの仕事をベンチマーキングするソフトウェア開発の実践です。通常、各人が少なくとも日に一回ベンチマーキングを行います。これにより一日に複数回のベンチマーキングが行われます。各ベンチマークは自動化されたビルドによって検証され、できるだけ早くパフォーマンスの低下を検出します。多くのチームは、このアプローチによってパフォーマンスの低下が大幅に減少し、チームがパフォーマンスの高いソフトウェアをより迅速に開発できるようになると感じています。

今や、ソフトウェア業界のすべての人が継続的インテグレーション（CI）について理解しています。基本的なレベルで、CIはソフトウェアの機能回帰が生産に入る前にこれを検出し、防止することについてです。同様に、継続的ベンチマーキング（CB）は、ソフトウェアの_パフォーマンス_回帰が生産に入る前にこれを検出し、防止することについてです。コード変更ごとにCIでユニットテストが実行される理由と同じように、コード変更ごとにCBでパフォーマンステストを実行するべきです。事実、このアナロジーはとても適切で、このセクションの最初の段落はただMartin Fowlerの2006年の継続的インテグレーションへの紹介のMad Libs版に過ぎません。

🐰 パフォーマンスのバグはバグです！

CIでのベンチマーク

神話：CIでベンチマーキングを実行できない

ほとんどのベンチマークハーネスは遅延やスループットを測定するためにシステム壁面時計を使用します。これは非常に役立ちます。なぜなら、これらは私たちが開発者として最も気にかけている具体的なメトリクスだからです。しかし、一般的な目的のCI環境は、壁面時計を測定するときにしばしばノイズが多く、不一致になります。継続的ベンチマーキングを行うとき、この変動性は結果に望ましくないノイズを加えます。

これを処理するためのいくつかの選択肢があります。

• 相対ベンチマーキング
• 専用のCIランナー
• 壁面時計と opposed to な指示を数えるハーネスに切り替える

あるいは、単純にカオスを愛してください！継続的ベンチマーキングは完璧である必要はありません。 はい、継続的ベンチマーキング環境での変動性を減らすことにより、ノイズを減らせば、より細かくパフォーマンスの低下を検出することができます。しかし、ここでは完璧さが良さの敵になることはないでしょう！

このグラフを見て、「ワオ、それは狂っている！」と思うかもしれません。しかし自問してみてください、現在の開発プロセスは、ユーザーに影響を与える前に、2倍、あるいは10倍のパフォーマンス低下を検出できますか？多分できないでしょう！それこそ_が_狂っていることです！

CI環境からの全てのノイズでも、壁面時計のベンチマークを追跡することは依然として、パフォーマンスの低下をそれらが生産でお客様に達する前に捉えることに大いに利益をもたらす可能性があります。時間と共に、ソフトウェアのパフォーマンス管理が成熟するにつれて、そこから構築することができます。その間は、ただ通常のCIを使用してください。

パフォーマンスは重要です

神話：100msの遅延は気づかない

人間は100msの遅延を知覚できないという主張を聞くことがよくあります。この主張のためにしばしば引用されるのはNielsen Groupの応答時間に関する記事です。

秒の0.1はユーザーがシステムが反応するために即座にユーザーの感覚を活用して反応していると感じる限度で、結果を表示するための特別なフィードバックは必要ないということです。

• Jakob Nielsen, 1 Jan 1993

しかし、これは単純には真実ではありません。一部のタスクでは、人々は2msの遅延だけでも知覚できます。これを証明する簡単な方法は、Dan Luuからの実験で、ターミナルを開き、sleep 0; echo "ping"を実行し、次にsleep 0.1; echo "pong"を実行します。違いに気付きましたか？

また、遅延の知覚と人間の反応時間との間の混乱がよくあります。視覚的な刺激に対して反応するのにおよそ200msかかるとしても、それはイベント自体の知覚とは独立しています。比喩によると、電車が2分遅れていることに気づくことができます(知覚される遅延)が、電車の旅行には2時間かかります(反応時間)。

パフォーマンスは重要です！パフォーマンスは機能です！

• 毎回100ms速く→1%のコンバージョン増(Mobify、年間＋$380,000/収益化）
• 50%速く→販売12%増(AutoAnything)
• 20%速く→コンバージョン10%増(Furniture Village)
• 40%速く→サインアップ15%増(Pinterest)
• 850ms速く→コンバージョン7%増(COOK)
• 毎回1秒遅く→ユーザー10%減少(BBC)

ムーアの法則の終焉とともに、並行して実行できるワークロードは並行化される必要があります。しかし、ほとんどのワークロードは連続して実行する必要があり、問題に対して単純にもっと計算を投げることは、急速に取り扱いができなくて高価な解決策になっています。

コンピューティングの変化に直面しているパフォーマンスの高い現代のソフトウェアを開発し、保守するための重要な要素が、継続的なベンチマーキングであることは明らかです。

継続的なベンチマーキングツール

Bencherを作成する前に、以下のことができるツールを見つけることを試みました:

• 複数の言語をまたがってベンチマークを追跡する
• 言語標準のベンチマークハーネス出力をシームレスに摂取する
• カスタムベンチマークハーネス出力に対応可能
• オープンソースで、自己ホスト可能
• 複数のCIホストとの連携
• ユーザー認証と認可

残念ながら、これら全ての基準を満たすものは存在しませんでした。我々がインスピレーションを得た既存のベンチマーキングツールの包括的なリストについては、既往の芸術をご覧ください。

ビッグテックでの継続的なベンチマーキング

Microsoft、Facebook(現Meta)、Apple、Amazon、Netflix、Googleを始めとした数え切れない他の企業で、Bencherのようなツールが内部開発されています。これらビッグテックの業界大手は、開発中のパフォーマンスを監視する重要性と、これらの洞察をCBを通じて開発プロセスに統合することを理解しています。私たちは、継続的なベンチマーキングをビッグテックの壁の内側からオープンソースコミュニティに提供するために、Bencherを構築しました。ビッグテックからの継続的なベンチマーキングに関連した投稿のリンクについては、既往の芸術をご覧ください。

Bencher: 連続ベンチマーキング

Bencherは、連続ベンチマーキングツールのスイートです。 パフォーマンスの後退があなたのユーザーに影響を与えたことはありますか？ Bencherなら、それが起こるのを防げた可能性があります。 Bencherは、パフォーマンスの低下を_productionに到達する_前に検出し、防止することを可能にします。

• 実行: お気に入りのベンチマーキングツールを使用してベンチマークをローカルまたはCIで実行します。 bencher CLIは単にあなたの既存のベンチマークハーネスをラップし、その結果を保存します。
• 追跡: ベンチマークの結果を時間と共に追跡します。ソースブランチ、テストベッド、測定基準に基づいてBencherのWebコンソールを使用して結果を監視、クエリ、グラフ化します。
• キャッチ: CIでパフォーマンスの後退をキャッチします。Bencherは最先端のカスタマイズ可能な分析を使用して、パフォーマンスの後退がProductionに到達する前にそれを検出します。

機能の後退を防ぐためにユニットテストがCIで実行されるのと同じ理由で、Bencherを使用してCIでベンチマークを実行してパフォーマンスの後退を防ぐべきです。パフォーマンスのバグはバグです！

CIでパフォーマンスの回帰を捉えるのを開始してください - Bencher Cloudを無料で試す。

継続的ベンチマークとローカルベンチマークの比較

ローカルで結果を比較できるいくつかのベンチマークハーネスがあります。 ローカル比較は、パフォーマンスチューニングを素早く反復処理するのに適しています。 しかし、継続的にパフォーマンスの低下を検出するために依存するべきではありません。 ユニットテストがローカルで実行できることがCIの必要性を否定しないのと同様に、 ベンチマークをローカルで実行して比較できることがCBの必要性を否定するものではありません。

Bencherが提供するローカルベンチマーク比較ツールでは提供できないいくつかの機能：

• 異なるテストベッド間での同一ベンチマークの比較
• 言語とハーネスを跨いだベンチマークの比較
• ベンチマーク結果の協力と共有
• ノイズを最小化するための専用テストベッドでのベンチマーク実行
• コピペはもう要らない

継続的ベンチマークとアプリケーションパフォーマンス管理 (APM)

アプリケーションパフォーマンス管理 (APM) は現代のソフトウェアサービスにとって重要なツールです。 しかし、APMは本番環境で使用することを目的として設計されています。 パフォーマンスの低下が検出されるときには、すでにお客様に影響を及ぼしています。

最も多くの欠陥は、それらを予防するためのコストを上回るほどになります。 欠陥が発生した時の直接的なコストと、破損した関係性、失われたビジネス、逸失した開発時間による間接的なコストの両方が高額です。

— ケント・ベック, 「Extreme Programming Explained」

Bencherが提供するAPMツールでは提供できないいくつかの機能：

• パフォーマンス低下を本番環境に出る前に検出し、防止することができる
• コードレビューにパフォーマンスの変更とその影響が含まれる
• 本番環境でのオーバーヘッドはなし
• オンプレミスの展開に有効
• 本番ソースコードへの変更は不要

継続的ベンチマークと観測性

名前が何であれ、美しいものは美しい。 上記の「継続的ベンチマークとアプリケーションパフォーマンス管理」を参照してください。

継続的ベンチマークと継続的インテグレーション (CI)

継続的ベンチマーク (CB) は、継続的インテグレーション (CI) と補完関係にあります。 ユニットテストが各コード変更ごとにCIで実行される理由と同様に、 パフォーマンステストは各コード変更ごとにCBで実行されるべきです。

ユニットテストと受け入れテストが標準的な開発プラクティスとして広く受け入れられている一方で、 この傾向はパフォーマンステストの領域にまでは続いていません。 現在、一般的なツールはテスターを廃棄可能なコードの作成とクリック＆スクリプトの思考方式に向かせる傾向があります。 パフォーマンステストを一等市民として扱うことで、より多くの機能をカバーするより良いテストを作成することが可能になり、 それによってより良いツールを作成してパフォーマンステストを実行することが可能になり、 結果としてテストスイートが保守可能で、それ自体がテスト可能になります。

— Thoughworks Technology Radar, 22 May 2013

継続的ベンチマークと継続的負荷テスト

継続的ベンチマークと継続的負荷テストの違いを理解するためには、 ベンチマーキングと 負荷テスト の違いを理解する必要があります。

ベンチマークは、機能レベル（マイクロベンチマーク）からサービスレベル（マクロベンチマーク）までのソフトウェアのパフォーマンスをテストすることができます。 ベンチマークは、コードの特定の部分のパフォーマンスを孤立してテストするのに適しています。 負荷テストは、サービスレベルでソフトウェアのパフォーマンスをテストし、複数の同時ユーザーを模擬します。 負荷テストは、特定の負荷のもとでのサービス全体のパフォーマンスをテストするのに適しています。

🍦 アイスクリームトラックのパフォーマンスを追跡したいとしたら、 ベンチマークは、アイスクリームコーンをスクープするのにどれくらい時間がかかるか（マイクロベンチマーク）や、 お客さんが注文してアイスクリームを受け取り、支払いをするのにどれくらい時間がかかるか（マクロベンチマーク）を測定するために使用することができます。 負荷テストは、猛暑の日に100人の顧客をどれだけ良くアイスクリームトラックがサービスできるかを見るために使用されることができます。

続ける: クイックスタート ➡