これは Azure Advent Calendar 2014 - Qiita の 24 日目の記事です。いつも通り Azure Web サイトネタで。
前から Azure Web サイトのファイルストレージはかなり遅いのではないかと思っていたので、アドベントカレンダーで良い機会なので簡単に調べてみました。特に最近は Ruby のランタイムをインストールしているので、同じような処理をするシェルスクリプトを書きました。
export PATH="$PATH:/d/7zip" # ファイルのダウンロード SECONDS=0 curl -LOs http://dl.bintray.com/oneclick/rubyinstaller/ruby-1.9.3-p551-i386-mingw32.7z echo "curl : $SECONDS sec" # 圧縮ファイルの展開 SECONDS=0 7za x ruby-1.9.3-p551-i386-mingw32.7z > nul echo "7za x : $SECONDS sec" rm -f ruby-1.9.3-p551-i386-mingw32.7z # 多数のファイルの削除 SECONDS=0 rm -rf ruby-1.9.3-p551-i386-mingw32 echo "rm -rf : $SECONDS sec"
ファイルのダウンロードに関しては回線状況によって左右されるので、多少のバラつきが出ることは覚悟してます。一番確認しておきたいのは展開と削除の処理時間です。
それではスクリプトが用意できたので、実際に Azure Web サイト上でパスを変えて実行してみます。
まずは揮発性だと思われるシステムドライブ上で実行した結果です。ユーザープロファイルを読み込むように設定しておけば、現在のユーザー用に書き込み可能なディレクトリが用意されます。
D:\Users\shibayan-api\Documents>bash benchmark.sh curl : 10 sec 7za x : 15 sec rm -rf : 4 sec
揮発性なディスクは仮想マシンに物理的に接続されているドライブになるので、かなり高速ですね。
次は永続化されていると思われるローカルディスク上で実行した結果です。
C:\DWASFiles\Sites\#1shibayan\Temp>bash benchmark.sh curl : 12 sec 7za x : 7 sec rm -rf : 5 sec
永続化されているディスクの方がシステムのディスクより早いのは、恐らくキャッシュが効いているのでしょう。テンポラリとして特にパフォーマンスを心配することなく使えそうです。
最後に Azure Web サイト間で共有されているストレージ上で実行した結果です。
D:\home\temp>bash benchmark.sh curl : 11 sec 7za x : 44 sec rm -rf : 87 sec
アーキテクチャ的にパフォーマンスが悪いのは分かってはいましたが、正直ここまで差が出るとは思っていませんでした。単一ファイルへの書き込みは他とほぼ同じですが、沢山のファイルに対しての操作は最大で 20 倍ぐらい遅いときがあります。
これまでに Ruby on Rails のアプリケーションや Movable Type を Azure Web サイトで動かしてきた時、どうしても初回のパフォーマンスが改善しなかったのですが、単純に実行時に多くのファイルを読み込む必要のある LL に対して、Azure Web サイトは弱いという話でした。
@shibayan Azure FilesがまともなACS実装したら同程度までは早くなると思われるけど（※
— こすもす.えび (@kosmosebi) 2014, 12月 23@shibayan すごい人たちが頑張ってるはずだから祈っておこう
— こすもす.えび (@kosmosebi) 2014, 12月 23考えてみると、ASP.NET アプリは基本的に dll という一つのファイルにまとめられるので、ストレージのパフォーマンスの影響を受けにくかったのでしょう。ASP.NET 5 で cs ファイルをそのまま置く時代になれば、めんどくさいことになりそうです。
追記
Twitter で帝国兵さんから重要な補足情報を頂きました。
Azure Websitesのストレージが遅いもう一つの理由はクォータ管理のせいです。xdriveでマウントしているVHDに対するFSRMが遅いんです。この辺りも含めてどう改善するか現在いろいろ試しつつ取り組んでます
— 帝国兵 (@superriver) 2014, 12月 23しばやん先生も書いてますが、多数の細かいトランザクションに弱いんですよね。プラットフォーム側でキャッシュさせるとコンシステンシに問題でるし。アプリ側がそのあたり意識して書いてもらう(jsのbundleみたく)というのが今のところ現実的かも
— 帝国兵 (@superriver) 2014, 12月 23ちなみに FSRM と言うのはファイル サーバー リソース マネージャ*1のことです。サイトごとの使用量を管理するために使っているのだと思われます。
細かいトランザクションに弱いのは、Blob をファイルサーバー経由で SMB マウントしてるからオーバーヘッドが大きいのが原因じゃないかと思っていましたが、ちょっと違っていたようです。
