スケジュールが遅れていた気がする .NET Core 2.1 / ASP.NET Core 2.1 ですが、Scott Hunter が Channel 9 の動画付きでブログを公開してました。
昔は ASP.NET の担当だった気がしましたが、今は .NET 全体の Director だったのですね。
People have been asking and happy to anouce our .NET Core 2.1 roadmap blog posts and videos are now going live. https://t.co/4CBReLh0Nn
— Scott Hunter (@coolcsh) 2018年2月2日
.NET Core 2.1 についてもブログでロードマップというか、強化される機能の紹介がされています。
詳しいことは @ufcpp がまとめてくれます。Span<T> / Memory<T> とかアプリでは直接触る機会少なそうですが、ライブラリの対応が進むと恩恵を受けられそうです。
個人的に気になったのはビルド速度の改善と HttpClient のパフォーマンス改善ですね。HttpClient は便利なのに正しく使うのが難しいという、地味に厄介な代物ですが .NET Core 2.1 からは楽になりそうです。
ASP.NET Core 2.1
2.0 からの Breaking Changes は大して無さそうなのでアップグレードは容易でしょう。HTTPS がデフォルトでオンになる点だけは注意が必要になりそうな感じがしますね。
Kestrel を直接インターネットに公開するようなことは基本的に行われないと思ってたのですが、主にローカル環境に対する変更なのかもしれません。普通は上のリバースプロキシとかで SSL offload しそうですし。
というような疑問点は以下の Issue にほぼまとまっているので確認しておきましょう。デフォルトでオンになるというのは、別に HTTPS に強制リダイレクトするという意味ではないです。
他には GDPR に関する変更が入ってきているので、もうちょっとじっくりと追いかけておきたいところです。後は Razor Pages と Web API に対する機能強化でした。
ASP.NET Core の SignalR は全然追いかけていなかったのですが、通信が JSON から MessagePack に変更になったらしいので、効率的な処理とスケーラビリティが改善しそうです。
まだリリースには時間がかかりそうな雰囲気ですが、ASP.NET MVC 5 から ASP.NET Core MVC 2.0 へ移行した際に、大幅にパフォーマンスとスケーラビリティが改善したので、新しい SignalR にも期待しています。
ANCM In-Process Hosting
ここまでは順当に機能強化と改善だったのですが、1 つだけ特殊な機能がありました。そうです、ASP.NET Core Module の In-Process Hosting です。
webdev のブログでは ~4.4x と書いてましたが、GitHub には 6x のスループットとありました。この辺りの触れ込みがかつての Helios を思い出す感じがしてアレですが、今回はソースも公開されています。
ASP.NET Core Module in-proc hosting - 6x the throughput on IIS! Better startup error handling
ASP.NET Core 2.1 high-level planning · Issue #288 · aspnet/Announcements · GitHub
大雑把に説明してしまうと、IIS が .NET Core なアプリケーションを直接ホスティングする仕組みになってます。IIS から ASP.NET Core アプリケーション間の TCP 通信が無くなるので、効率的になるという話です。
当然ですが ANCM なので IIS を使っている場合のみ影響します。従って App Service で ASP.NET Core アプリケーションを動かしている場合や、Azure Functions v2 を使っている場合には 2.1 がリリースされた際に改善が期待できます。
既に GitHub では In-Process に対応したコードが公開されてるので、仕組みを調べることができます。
in-process という分かりやすいディレクトリでコードが分けられているので軽く読んでみると、hostfxr という文字がちょいちょい出てきます。
hostfxr については藤原さんが超絶わかりやすい解説を書いてくださっているので、そちらを参照ください。
ANCM 側では hostingModel が inprocess に設定された場合、ASP.NET Core アプリケーション側から Request Handler などのコールバックが設定されるまで 500 エラーを返すように実装されていました。
そのコールバックの設定を誰がやるのかという話ですが、これは IIS Integration Middleware が行っています。
ANCM がエクスポートしているネイティブメソッドを呼び出して、HTTP リクエストなどを処理するコールバックを設定していました。多少ここでマーシャリングコストが発生しそうですが、TCP を使った通信と比べると非常に小さいものです。
まだ実際に動かしてみたわけではないので、コードを読んだ上での推測にはなりますが、確かにパフォーマンスは改善するだろうなと思う内容でした。
場合によっては前に nginx を置いた場合といい勝負が出来るかも知れません。2.1 に期待しましょう。
