BlackJumboDog .NET Core 性能向上 メモ1

BlackJumboDog .NET Coreの性能を向上させようといろいろ模索する中での話。

今やっていた性能向上というのは、WebServerで、クライアントからの接続要求をどれくらい処理できるか?です。
具体的には、Fiddlerを使って、1000回~100000回のリクエストを処理させて、エラーがおきないように、そして500回あたりのリクエスト(FiddlerがTimelineをグラフ化してくれるサイズ)をどれくらい早くできるか?

そんなところで、比較対象がなければということで、MSのIIS(InternetInfomationService)を手っ取り早いところで、相手にしてみました。Hyper-VのゲストOSとして、Windows Server 2016 を。リソースは、4コアのメモリ4GBをあてました。検証で利用するファイルは、BJDの初期で入っているindex.htmlです。サイズは4Kb強

IIS on Windows Server 1

私が注目したのはまず、右上に出ている78msという時間。これはこのグラフ全体が78msということっぽいようで、500回のリクエストを80ms以内にすべて応答しているということです。グラフの色が出ているところが通信中の状態(HTTPリクエストからレスポンスが返るまで)で、空白が、何もしていない時間のようです。こうしてみたとき、空白の領域は多く、Fiddlerが遊んでる状態といいますか、サーバーとクライアントはKeepAliveによってただSocketがつながっているだけの状態。1リクエストは数msで処理されている状態。

 

対して、BlackJumboDog .NET Coreはというと・・・

全体が、500ms。グラフもぎりぎりまで密集しており、空白はほとんどない。リクエストからレスポンスまでの時間が長く、Fiddlerが待っている状態。

リクエスト数に対しての処理時間でいけば、単純に1msとなりますが、並列で動いているために、1リクエストは実際のところ10ms、20msとかそんな感じ。

一日に数回しかないような処理ならば、速いものですが、このリクエストはブラウザ一つで、ページの読み込み、スクリプトの読み込み、画像リソースの読み込みとか考えたとき、1ページ表示するのに重ければ、10回以上はあるでしょう。

これを考えたとき、静的なファイルはダウンロードさせずに、ブラウザにキャッシュ化したり、リクエスト数を減らすためにファイルを結合してみたりとか、トラフィックがネックであれば、GZIP圧縮をかけてみたりといったこともできます。

ですが・・・それでは面白くない。
実際、これだけの差があることを.NET Coreのせいにしてしまうというのも一つなのですが、.NET Coreでも、KestrelというASP.NET Coreを動かすシンプルなアプリケーションサーバーは、ものすごい勢いでリクエストを処理できたりします。(実際はアプリケーションの処理によってはそんなに早くならないですが)

https://github.com/aspnet/KestrelHttpServer

 

そこで、何とか早くならないかと模索してみた・・・つづく