「Hello、world！」よりも複雑なソフトウェア製品はすべて、テストの公理です。 また、機能が広くなり、アーキテクチャが複雑になるほど、テストに注意を払う必要があります。 粒度の高いパフォーマンス測定では、特に注意する必要があります。 1つの部分で加速し、別の部分で減速した結果、結果がゼロになることがよくあります。 これを防ぐために、作業ではいわゆるアトミックテストを非常に積極的に使用します。 それは何で、彼らは何を食べますか、カットの下で読んでください。
背景
Parallels Desktopの進化に伴い、個々の機能をテストすること、および定期的な更新と最適化の後、仮想マシンのパフォーマンス低下の原因を見つけることがますます困難になりました。 システムが複雑であるため、単体テストで完全にカバーすることはほとんど不可能でした。 また、標準のパフォーマンス測定パッケージは、私たちにとって未知のアルゴリズムで動作します。 さらに、仮想環境ではなく、実際の環境での測定のためにシャープ化されています。つまり、標準ベンチマークは加えられた変更に「敏感」ではありません。
単体テストの場合のように大きな人件費を必要とせず、ベンチマークと比較して感度と精度が優れた新しいツールが必要でした。
原子テスト
その結果、高度に専門化された一連のアトミックテスト、アトミックテストを開発しました。 それらはそれぞれ、いくつかの典型的なハイパーバイザーの仕組み（VM出口の処理など）またはオペレーティングシステム（TLBシュートダウンによるTLBキャッシュのフラッシュ、コンテキストの切り替えなど）のパフォーマンスを測定するように設計されています。 また、アトミックテストを使用して、オペレーティングシステムと仮想マシンの実装に依存しない単純な操作（数学計算、異なる初期条件でのメモリとディスクの操作など）のパフォーマンスを評価します。
各テストの結果は、特定のメトリックの値です。 一部のメトリックは相互接続され、他のメトリックは相互接続されません。 標準ベンチマークの自動実行中に取得した情報で、アトミックテストの結果を補完します。 テスト中に取得したデータを分析すると、どのサブシステムで何が起こったのかを知ることができます。
解決すべき課題
もちろん、機能自体をテストすることは、機能するか機能しないか、機能する場合は正しいですか？ -重要かつ必要なもの。 ただし、これは、アトミックテストを使用して解決するタスクの範囲に限定されません。
まず 、生産性が低下する理由を探しています。 これを行うために、定期的にアトミックテストを実行し、それらのいずれかがリグレッションを示した場合、標準の二分手順を使用します。
また、次のテストでリグレッションが明らかになり、バグが発表されましたが、開発者はすぐに原因を把握できません。 そして、手がまだ届くと、バグが簡単に再現される条件はすでに失われている可能性があります。 一部のタスクでは、非常に大きなバックログがあり、すべての変更を逆の順序でテストするのは長すぎて時間がかかります。 生産性の低下がいつ発生したかが正確にわからないこともあります。 そのような場合、プログラマーは、対応する機能を繰り返しテストし、さまざまな条件でシステムの動作を調べ、デバッグシステムログを分析して、テストの記述された回帰の理由を見つけます。
アトミックテストの助けを借りて解決される2番目のタスクは 、競合他社との比較です。 2つのシステムを使用し、異なるハイパーバイザーの下で同じマシンでテストします。 一部の領域で製品のパフォーマンスが劣っている場合、開発者はその理由を慎重に理解し始めます。
3番目のタスクは、最適化の有効性を判断することです。 すべてが迅速に機能する場合でも、開発者は定期的にアーキテクチャとパフォーマンスを改善するためのアイデアを持っています。 また、アトミックテストは、イノベーションが製品にメリットをもたらしたかどうかをすばやく見つけるのに役立ちます。 多くの場合、最適化を行ってもパフォーマンスは改善されず、場合によってはさらに悪化することもあります。
アトミックテストを使用する機能
アトミックテストは、ホストまたはゲストOSのどこでも実行できます。 ただし、パフォーマンステストと同様に、オペレーティングシステムとハードウェアの構成に依存します。 そのため、ゲストと一致しないホストOSでテストを実行すると、結果は役に立たなくなります。
他のパフォーマンステストと同様に、再現可能な結果を生成するには特定の条件が必要です。 ホストOSは非常に複雑で（仮想化システムのおかげ）、リアルタイムオペレーティングシステムではありません。 機器に関連する予測できない遅延が表示される場合があり、さまざまなサービスがアクティブになる場合があります。 ハイパーバイザーは、ユーザー空間、カーネル空間、および独自のコンテキストで実行される多数のコンポーネントで構成される複雑なソフトウェア製品でもあります。 ゲストOSは、ホストと同じ問題の影響を受けます。 そのため、アトミックテストを使用する際の最も難しいことは、テスト結果の再現性を取得することです。
どうやってやるの？
安定した結果を得るための最も重要な条件は、常に同じ初期条件の下で、ロボットによるテストの開始です。
•ネットブートシステム
•同じ場所で、バックアップから物理ディスクに毎回同じ仮想マシンが復元されます
•テストは同じアルゴリズムを使用して直接実行されます
測定条件が変更された場合、彼は合理的な説明を求め、結果は常に変更の前後で比較されます。
人生の例
ユーザー空間にあるコンポーネントを使用して処理を実行する必要がある場合、ハイパーバイザーは独自のコンテキストからカーネルコンテキストに切り替え、次にユーザー空間のコンテキストに切り替える必要があります。 また、ゲストOSに割り込みを渡すには、次のものが必要です。
1）まず、ホストOSからの信号を使用して、アイドル状態から仮想プロセッサスレッドを削除します
2）コンテキストから独自のハイパーバイザーコンテキストに移動する
3）割り込みをゲストOSに渡す
問題は、ハイパーバイザーコンテキストからカーネルコンテキストへ、またはその逆への切り替えが非常に遅いことです。 また、仮想プロセッサがアイドル状態のときに、制御を戻すと、非常に高いコストが発生します。
Parallels DesktopでMacOS X Yosemite 10.10のバグに遭遇しました。 システムは、処理したことだけを行うほどの強度でハードウェア割り込みを生成し、その結果、ゲストOSがハングしました。 この状況は、ゲストOSのコンテキストで受信したハードウェア割り込みをすぐにホストOSに転送する必要があるという事実によって悪化しました。 このため、コンテキストを2回切り替える必要があります。 また、このような中断が多数発生すると、ゲストOSの速度が低下またはハングします。 これが、アトミックテストが便利になった場所です。
問題が10.10.2で修正されたという事実にもかかわらず、これがもう起こらないようにし、ゲストOS全体を高速化するために、特別なアトミックテストを使用してコンテキスト切り替え手順を徐々に最適化し、現在の速度を定期的に測定しました。 たとえば、完全に独自のコンテキストで実行する代わりに、カーネル空間のコンテキストにより近いコンテキストに実行を移動しました。 その結果、切り替え中の操作の数が減少し、ユーザー空間のコンポーネントへの要求の処理速度と、休止状態からゲストオペレーティングシステムへの制御の移動が増加しました。 最後に、誰もが幸せです！
記事へのコメントで質問にお答えします。 また、何か不明瞭に思えるかどうかを尋ねます。