概要
以前の記事で、Azure VM＆Azure Pipelinesのビルド環境へDevDriveを導入してみました。これにどれほどのビルド加速効果があるのか、測定してみようと思います。
結果まとめ
内訳に興味が無い人向けに、最初に結果をまとめておきます。こんな感じになりました。
- 効果はいまいちで、ビルド時間が数%減るか減らないかくらい
- むしろCPU強化のほうが効果があったので、そのあたりがネックにならないリッチなビルド環境向けかも
- 少なくともマイナスではなかったので、ダメ元で導入してみても良いと思う
測定
測定のやり方
次の条件で、実際にパイプラインを動かして所要時間を測定していきます。
- 測定対象
- 1，C#とC++(WDK)の小規模ソリューション（非公開・手元にあったもの）
- C#部分は発行（publish）、WDK部分はビルド
- 2，OrchardCore
- MSのブログで、DevDriveのパフォーマンス例で22%改善としていたもの
- VisualStudio2022で、ソリューション構成Release/Any CPUをビルド
- 測定条件（組み合わせて測定する）
- VMのサイズ
- Standard_D4ds_v5
- Standard_F8s_v2
- ストレージ
- 一時ディスク（Dドライブ）
- データディスク Premium SSD
- DevDrive
- パーティション全体をDevDriveに設定（Premium SSDのみ）
- vhdファイルを作成してマウントし、DevDriveに設定（一時ディスクのみ）
- DevDrive無し（通常のNTFS）
- VMのサイズ
- 測定方法
- 2～3回ほどパイプラインを実行して、パイプライン実行結果に記録された所要時間を見る
- 対象条件での初回の実行結果は捨て、2回目以降の実行結果を採用する
- あまり効果が見られないため、途中から一部組み合わせの測定をカットしたり回数を減らしたりしている
- 2～3回ほどパイプラインを実行して、パイプライン実行結果に記録された所要時間を見る
測定結果
条件別に、次の対象の測定結果を表にまとめます。測定結果の単位は全て秒です。
- 対象1：測定対象1のcheckout
- 対象2：測定対象1のC#ソリューション発行
- 対象3：測定対象1のWDKビルド
- 対象4：測定対象2のNuGet復元
- 対象5：測定対象2のソリューションビルド
Azure VM Standard_D4ds_v5
データディスクでは、ほとんど差が無いという印象です。一時ディスクのほうでは、数%くらいはDevDriveのほうが優れてるかも・・・？というところでしょうか。動きを見ているとCPUが一番ネックになっていそうにも見えるので、CPUが強そうなサイズに変えてみます。
| ストレージ | 対象1 | 対象2 | 対象3 | 対象4 | 対象5 |
|---|---|---|---|---|---|
| データディスク NTFS | 8～20 | 53～61 | 10 | 19～20 | 98～108 |
| データディスク DevDrive | 7～12 | 53～60 | 10～11 | 19～23 | 103～111 |
| 一時ディスク NTFS | 10～19 | 57～62 | 11～13 | - | - |
| 一時ディスク DevDrive | 7～10 | 54～58 | 10 | - | - |
Azure VM Standard_F8s_v2
もう少し効果が明確になった印象でしょうか。せいぜい5％がいいところですが、確かに改善はしているように見えます。もしかして、IOPS制限などAzure VM固有の要素に影響されているのかもしれないので、ローカルのHyper-Vも試してみます。
| ストレージ | 対象1 | 対象2 | 対象3 | 対象4 | 対象5 |
|---|---|---|---|---|---|
| データディスク NTFS | 9 | 78 | 13 | 24 | 85～100 |
| データディスク DevDrive | 9～11 | 68～75 | 13 | 24～27 | 91～95 |
| 一時ディスク NTFS | - | - | - | 25～28 | 92～100 |
| 一時ディスク DevDrive | 15 | 73 | 13 | 24～26 | 84～95 |
Hyper-V（あまり性能は良くない）
適当に確保したローカルのHyper-V環境での測定です。さほど性能が良いものではありません。こちらでは10%程度の改善はしているように見えます。Azure VM固有の要因が悪いと言えるほどのデータではありませんが、条件によっては改善幅が大きくなるものと期待はできます。
| ストレージ | 対象1 | 対象2 | 対象3 | 対象4 | 対象5 |
|---|---|---|---|---|---|
| システムドライブ NTFS | - | - | - | 22～24 | 100～112 |
| システムドライブ上のvhd DevDrive | - | - | - | 24～28 | 89～108 |
考察
MSのブログで出ているような22％もの改善は得られませんでした。とはいえ、ストレージが大きなネックになっている環境では、5～10％程度の改善は出ているように見えます。当たり前といえばそうですが、ストレージ以外がネックになっている場合は効果は出づらいようです。もしかするとDevDriveは、もっと各種スペックが高くてストレージだけがどうしてもネックになる、というようなリッチなビルド環境でこそ力を発揮するのかもしれません。
いずれにしても、「DevDriveにしたら、かえって悪化した」ということはなく、使って損はないようです。
Azure VMにおいては、高価なPremium SSDを使っても一時ディスクと速度に大差はありませんでした。追加コストを支払ってデータディスクを追加するよりも、一時ディスクを使うほうが良さそうです。
まとめ
DevDriveを使用した場合には、22%という大きな改善効果こそ見られなかったものの、使って損はない程度の改善は見られました。以前の記事に書いたように、一時ディスク上に確保してとりあえず使ってみる価値はあるように思います。色々な条件に左右されるので、もしかして用途によっては大きな改善を得られるかもしれません。