AppVeyorのテストでエラー

前回のログ出力をがっつり作り替えたところのそもそも理由

AppVeyor Bjd.SmtpServer.CoreCLR.Test  1.1.0-51

で、エラーとなっている部分があるんですが、
これはローカルのWin10、VS2015環境では問題なく通るテストなのです。
このテストケース。
実際にSocketサーバーが動いて、それにクライアントが接続にいって
Pop3クライアントとしてメールを受け取るタスクを検証しているのですが、
メインではなく、裏で動いているPop3サーバーにてメールを開いたときのサイズが変わってしまってました。

AppVeyor(抜粋)

[13:38:12.326][1400][151] Mail.Read C:\projects\bjd5-qqab7\Bjd.SmtpServer.CoreCLR.Test\bin\201702191338066076_9_1333341264_23264094\mailbox\user2\MF_00635026511425888292 300 byte.
[13:38:12.326][1400][151] 16189196 SockTcp.SendNoTrace 151
[13:38:12.935][1400][151] 16189196 SockTcp.SendNoTrace 55
[13:38:13.545][1400][151] 16189196 SockTcp.SendNoTrace 12
[13:38:13.951][1400][151] 16189196 SockTcp.SendNoTrace 38
[13:38:14.154][1400][151] 16189196 SockTcp.SendNoTrace 37
[13:38:14.560][1400][151] 16189196 SockTcp.SendNoTrace 1
[13:38:14.967][1400][151] 16189196 SockTcp.SendNoTrace 5
[13:38:15.576][1400][151] 16189196 SockTcp.SendNoTrace 1
[13:38:15.982][1400][151] 16189196 SockTcp.SendNoTrace 2
[13:38:16.388][1400][151] 16189196 SockTcp.Send 3

ローカル

[23:46:07.939][13628][ 26] Mail.Read C:\Users\[username]\Source\Repos\bjd5\Bjd.SmtpServer.CoreCLR.Test\bin\201702212346077840_5_1610115599_50579406\mailbox\user2\MF_00635026511425888292 308 byte.
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 152
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 56
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 13
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 39
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 38
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 2
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 6
[23:46:07.940][13628][ 26] 18701856 SockTcp.SendNoTrace 2
[23:46:07.941][13628][ 26] 18701856 SockTcp.Send 3

トータル 300 byteに308 byte
さらに1行単位の送信では1バイトづつ違うー!
そして、送信してる行数も違う・・・

そもそも、単体テストを実行するような環境でSocketがっつりかましてるのどうなのか!というところもありますが。

おそらくは、改行コードじゃないかなぁ
・・・というところでここまでっ

How to output log for xUnit

ひさしぶりに BlackJumboDogをいじっていて、
ずーっと気になっていたことがあったので、思わずやってしまった・・・。

xUnitでは、並列テストを前提とした場合標準出力に対する出力をキャプチャしない仕様になっている。そのため、出力させるためには、独自のOutputHelperが必要になる。
※ Capturing Output

これやるにあたって、今のSystem.Diagnostics.Traceを全て置き換える必要が
あった。

なぜかというと、System.Diagnostics.Traceは、コンテキストを持たずアプリケーション内で静的に動作してしまうため、並列で動いたときはどのテストの結果であるかを知ることができない。

そのため、ちゃんとやるなら、System.Diagnostics.Traceを全て独自のものに置き換える必要があったが、それにはかなりの修正量になるのがあってためらっていた。

しかしながら、実際のところテストがエラーになったとき、単純なものであればよいが、複雑なものであれば、どこがどうなっているかというのを追いかける必要がある。そのためには、ログも実行された結果がそのまま出てくれているのが良く、関係のないところの情報が出ていることは、逆に紛らわしい。そのため単独で動かしてその結果が出てくれるならいいがそうではなかったりもする。まぁその時点でテストとしての精度が低いという問題もあるのだけれども。

そこで、ログもすべて自分の実装でコンテキスト化してしまおうというのをやってみた。

・ログは出力先が不特定多数(ファイル、コンソール、xUnit、その他)
・ログは気軽に出すことをできるようにしておき、必要に応じて出力できないようにする
・ログはルートのコンテキストに紐づける

といったような考えで挑んでみたところ。

悪くはないが、そのための影響が大きくやはりやりすぎだったか!と思いつつ、前に進んでいることで何かやる気が出てきている今日だった。

change internal architecture for log. 

独自で実装しておくことは、チューニングしやすくなるので、悪くはない。

もし、今後xUnitを用いた開発をするのであれば、ログを出力する機構を
テストごとにコンテキスト化できるような仕組みをお勧めしたいなぁと思った。

 

Azure Managed Disks – stripe 32 disks

びっくりなことに、仮想マシン上で扱えるディスクに
Managed Disksというものが追加された。
それまで、Azureの仮想マシンでは、StorageアカウントにBlobとしてVHDが追加される形で、少しややこしい部分もあり、物理的なVHDファイルを置いておきながら、仮想マシン独自の形で関連付けられていた。
Managed Disksは一つのリソースで一つのディスクと扱えるようになっており、現実世界のディスク1枚または、VHD1つのように考えることができて、サイズの指定もできて料金もわかりやすくなった。

価格

Managed Disks の価格

種類

大きく2種類。

<Premium>

SSDベースな、IOPS、スループット重視な
P10、P20、P30

 

<Standard>

HDDベースな
S4、S6、S10、S20、S30

 

仮想マシン

SSDベースなものは、接続できる仮想マシンのサイズが決まっているようです。DSシリーズ、DS_V2シリーズ、FSシリーズ、GSシリーズ。とSがついているやつ。

AzureのVMには、サイズによって最大IOPS、スループットが制限されるという仕様があるので、サイズの小さいインスタンスでは、思ったほどでないかもしれないですね。最大接続可能なManaged Disksの数も同様にサイズの制限を受けるようです。

Managed Disks 接続

ポータル上からぽちぽちクリック。旧来のようなストレージアカウントがあって、VHDファイルがあるというような実体はない様子。

1.Managed Disksのインスタンスを作成する

2.仮想マシンのディスクに接続する

だけ。

うん。このままだと面白くないので、少し試してみよう!

 

複数束ねてStripe

ディスク-ストライピング

というわけで試してみたこと。
D、DSでデプロイ。
接続するディスクはすべてホストキャッシュの読み取り書き込みを有効にしている。
仮想マシン内で、Stripeしている。

Standard Disk16 Disk32
(per 64GB)

Premium Disk10 Disk20 Disk32
(per 1TB)

おまけ、Temp(D:ドライブ)

わかったこと

Standardを32束ねても、Premiumには追い付かない!
コンシューマのSSDとベンチマークの結果だけで判断してはいけない。
(このディスクが物理ディスク一つではなく、冗長化された存在であることを忘れない)
また、揮発性の用途でよければ、Tempを使う選択肢がある。
大量にPremiumを接続する場合では、最大スループットは、ディスク側ではなく仮想マシン側の制約を受けているためか、20と32に差はほとんどなかった。
なお画像では、32のほうが低いようにみえるが、ホストキャッシュの影響か、非常に安定しない結果となった。ホストキャッシュの無効化によってまた異なる結果が出ると思われる。加えてStripeはファイル・アクセスごとに都合よく負荷分散をするためのものではないことも影響する一つと思われる。

また、この結果は個人的なもので、何かを保証するものではありません。

アプリ

CrystalDiskMark