検索
タグ
ASP.NET
.NET
ASP.NET MVC
Visual Studio
F#
Azure
ASP.NET Core
ライトニングトーク
Plone
Selenium
AJAX
C#
jQuery
ADO.NET Entity Framework
SQL Server
JavaScript
LINQ
EFCore
WebMatrix
PowerShell
カテゴリ
最新の記事
最新のコメント
記事ランキング
最新のトラックバック
以前の記事
2024年 10月 2024年 09月 2024年 08月 2024年 04月 2024年 03月 2024年 02月 2024年 01月 2023年 12月 2023年 11月 2023年 10月 2023年 09月 2023年 08月 2023年 07月 2023年 06月 2023年 05月 2023年 04月 2023年 03月 2023年 02月 2023年 01月 2022年 12月 2022年 11月 2022年 10月 2022年 09月 2022年 08月 2022年 07月 2022年 06月 2022年 05月 2022年 04月 2022年 03月 2022年 02月 2022年 01月 2021年 12月 2021年 11月 2021年 10月 2021年 09月 2021年 08月 2021年 07月 2021年 06月 2021年 05月 2021年 04月 2021年 03月 2021年 02月 2021年 01月 2020年 12月 2020年 11月 2020年 10月 2020年 09月 2020年 08月 2020年 07月 2020年 06月 2020年 05月 2020年 04月 2020年 03月 2020年 02月 2020年 01月 2019年 12月 2019年 11月 2019年 10月 2019年 09月 2019年 08月 2019年 07月 2019年 06月 2019年 05月 2019年 04月 2019年 03月 2019年 02月 2019年 01月 2018年 12月 2018年 11月 2018年 10月 2018年 09月 2018年 08月 2018年 07月 2018年 06月 2018年 05月 2018年 04月 2018年 03月 2018年 02月 2018年 01月 2017年 12月 2017年 11月 2017年 10月 2017年 09月 2017年 08月 2017年 07月 2017年 06月 2017年 05月 2017年 04月 2017年 02月 2017年 01月 2016年 12月 2016年 11月 2016年 10月 2016年 09月 2016年 08月 2016年 07月 2016年 06月 2016年 05月 2016年 04月 2016年 03月 2016年 02月 2016年 01月 2015年 12月 2015年 11月 2015年 10月 2015年 09月 2015年 08月 2015年 07月 2015年 05月 2015年 04月 2015年 03月 2015年 02月 2015年 01月 2014年 12月 2014年 11月 2014年 10月 2014年 09月 2014年 08月 2014年 06月 2014年 04月 2014年 03月 2014年 02月 2014年 01月 2013年 12月 2013年 10月 2013年 09月 2013年 08月 2013年 07月 2013年 06月 2013年 05月 2013年 04月 2013年 03月 2013年 02月 2013年 01月 2012年 12月 2012年 11月 2012年 10月 2012年 09月 2012年 08月 2012年 07月 2012年 06月 2012年 05月 2012年 04月 2012年 03月 2012年 02月 2012年 01月 2011年 12月 2011年 11月 2011年 10月 2011年 09月 2011年 08月 2011年 07月 2011年 06月 2011年 05月 2011年 04月 2011年 03月 2011年 02月 2011年 01月 2010年 12月 2010年 11月 2010年 10月 2010年 09月 2010年 08月 2010年 07月 2010年 06月 2010年 05月 2010年 04月 2010年 03月 2010年 02月 2010年 01月 2009年 12月 2009年 10月 2009年 09月 2009年 07月 2009年 06月 2009年 05月 2009年 04月 2009年 03月 2009年 02月 2009年 01月 2008年 12月 2008年 11月 2008年 10月 2008年 09月 2008年 08月 2008年 07月 2008年 06月 2008年 05月 2008年 04月 2008年 03月 2008年 02月 2008年 01月 2007年 12月 2007年 11月 2007年 04月 2007年 03月 2007年 02月 2007年 01月 2006年 11月 2006年 10月 2006年 09月 2006年 08月 2006年 07月 |
2020年 10月 30日
実は11年前(!)にも試してみてたテーマ今回は C# による Web アプリケーション開発、とりわけサーバー側実装の話。 いわゆる ASP.NET Core における話だ。 で、ASP.NET Core による Web サーバー実装で、実際のところ、いったいどれくらいのサイズのファイルをアップロード可能なのか? というのが今回のテーマだ。 実はこのテーマ、なんと 11年前 (!) に ASP.NET (Core ではない!) で試したことがあって、本ブログサイトに記事が残っている。 このテーマを、ちょっとした要件があって、2020年、ASP.NET Core で改めてやってみることになった。 で、先に結論書いておくと、 たいした工夫なしで 10 GB 超のファイルを HTTP POST できてしまった。 以下はその顛末。 ごくごく、実直な実装さて「ブラウザ経由で、ファイルを Web サーバーにアップロードする」という命題なわけだが、今どきはブラウザもずいぶん進化した。 先の 11 年前のブログ記事だと、IE のバージョンが 8 (!) で、そもそもブラウザが 2GB までしか要求送信できないっぽいという、そんな時代だったが、近代ブラウザではそんなこともなくなっていることだろう、と想像。 加えて、JavaScript によるクライアント側実装も組み合わせるなど、いろいろなやり方があることだろう。 しかし今回は前回のブログ記事と同様、至極シンプルに、input type=file を用いた form でファイルを HTTP POST するというシナリオでやってみる。 まず、ブラウザ側に読み込まれる HTML コンテンツは以下のような感じだ。
なんてシンプル。 で、C#、ASP.NET Core によるサーバー側実装だが、今回は MVC/API Controller 方式でいく。 Razor Pages 方式でもいけるのだろうが、いずれ取り組んでみたいということに留め、今回は扱わない。 ということで、サーバー側コントローラーを実装する。 なお、今回の興味はアップロードできるファイルサイズの大きさだけなので、アップロードされたファイルの保存方法については頓着しない。 なので、受信した内容を Stream.Null に書き捨ててもよい。 しかしそうはいっても、いちおう動作確認しやすいよう、そのままサーバー側のファイルシステムに保存するだけとしよう。 ざっくり、正味だけ抜き出すと以下のような感じだ。
サーバー側実装も、何の工夫も変哲もなし。 アクションメソッドにバインドされたファイルオブジェクトを、そのままファイルのストリームにコピーするだけだ。 実行してみたさてこうして実装した ASP.NET Core Web アプリをいよいよ実行する。 dotnet CLI で開発中なら、単純に「dotnet run」で問題ない。 但し、とりわけ Windows 上で Visual Studio を使って開発している場合、ここで、この ASP.NET Core Web アプリの前段に IIS が噛んでいると、IIS 側の制約とかややこしいことになる。 まずは、IIS などのフロント側サーバーなしで、ASP.NET Core アプリ内の Kestrel サーバー直で動作するようにしよう。 Visual Studio であれば、ツールボタンで、IIS 上で動かすか、プログラムを直接実行するか選ぶことになると思うので、適宜選択されたし。 で、こうして実行した Web フォームを介して、大きめのファイルを送信してみる。 手元に 200MB 程のファイルがあったので試してみたところ、これはあっけなくエラー。 既定の設定ではファイルが大きすぎる (たかだか 200MB 程だが) と、アクションメソッドにバインドされる引数が null となってしまうようだ。 まぁ、想定内の挙動である。 リミッタ解除!しかしこれが ASP.NET Core の限界というわけではない。 どちらかといえばセキュリティ的な観点で設定された、既定の限界値設定の結果だ。 公式ドキュメントにも記載があるが、ちょこっとコードに属性指定を書き足してやることで、この "リミッター" を明示的に解除することが可能である。 具体的には、以下のように、2つの属性指定をアクションメソッドに追記する。
さぁ、これでコード上の限界値指定は long.MaxValue、すなわち、8,192 ペタバイト (8 エクサバイト) まで広がった。 メモリがめきめき消費され... ない!?とはいえ、実際には物理的なコンピューター資源の限界がある。 とりわけ、物理メモリ量や、そもそものメモリ空間上の限界は小さいはずだ。 そして限界値も気になるが、たかだか 1GB や 2GB 程度のファイルのアップロードだとしても、プロセスのメモリ消費量はめきめき上昇するだろう。 きっと .NET Core ランタイムのメモリマネージャが悲鳴を上げるのではないだろうか? ということで、まずは都合良く 1.6 GB 程のファイルが手元に転がっていたので、これをアップロードしてみた。 ところが、である。 すこうし処理時間がかかったとはいえ、あっけなく処理が正常完了したのである。 さらにである。 自分はこれを Windows 10 上で実行し、タスクマネージャを開いてメモリ消費量を眺めていたのであるが、一向にメモリ消費量が増えないのである。 当初の予想を裏切られ、肩透かしを食らってしまった格好だ。 怪訝に思いながらも、じゃぁ、どれくらいのファイルサイズをアップロードしたら影響がでるのか、ファイルサイズのより大きいファイルを選んで試験を続行した。 3GB でも問題ない。 4GB でもびくともしない。 ついに 10GB でもアップロードできてしまった。 しかもタスクマネージャのメモリ消費量も一定のままである。 一体どうなっているのか?? 何かファイルに猛烈に書き込みしてる...!よくよくタスクマネージャのグラフを表示を眺めていたところ、メモリではなく、ディスクの負荷状況が興味深い動きをしていることに気がついた。 前述の C# コードが動き出すより前から、ずっと、ディスクの書き込み処理が行なわれているっぽいのだ。 アップロードする元のファイルの読み取りや、あるは前述の C# コードによる、受信したファイル内容のファイルへの書き込みであればわかる。 が、どうもそれ以外のディスク書き込みが発生しているようなのだ。 これはいったいどんなファイル書き込みが発生しているのか気になり、リソースモニターを開いて調べてみた。 そうしたところ、なんと、テンポラリフォルダの "ASPNETCORE_...." というファイルに猛烈に書き込みが発生しているのを発見した。 デバッグ実行などしながら確認してみると、どうやら、ブラウザから送信された巨大な POST 要求は、まずはこの一時ファイルに保存されるようだ。 そしてブラウザからの POST 送信がすべて着信終了した・この一時ファイルへの保存が完了してから、その次に、コントローラーのアクションメソッドの実行が始まるようなのである。 すなわち、前述の C# 実装における、IFormFile から読み取れるストリームは、先の一時ファイルにつながっているようなのだ。 何でもメモリではなく、一時ファイルを活用しているっぽい自分は Web Forms の頃から ASP.NET に触っていたため、ついうっかり、アクションメソッドにバインドされる引数オブジェクト類は、すべてオンメモリ上にバッファリングして構築されてからアクションメソッドに引き渡されると思い込んでしまっていた。 しかしながら、ASP.NET Core では、オンメモリ上に何でもバッファリングしてしまうのではなく、ファイルシステムを使って一時ファイルを作ることで、巨大な要求を処理可能としているようだ。 ということで、ファイルシステム上の一時ファイルが肩代わりしてくれるおかげで、処理速度的には難ありとは思うが、とにかくクラッシュしたりメモリをバカ喰いすることなく、10GB 超のファイルを、何の工夫もないシンプルな Web フォームおよび ASP.NET Core コントローラー実装にて捌くことができることがわかった。 IIS のリミッタも緩和さて、Windows 上の Web サーバーサービスである IIS が絡む場合。 とくに Azure Web Apps の Windows プラットフォーム上へのこのような ASP.NET Core アプリを配置する場合は、IIS による制限も避けられない。 Windows 上で Visual Studio を使って開発している場合は、Visual Studio のツールバー上から、IIS 上での実行を選択してから実行すれば、IIS 上での実行を確かめられる。 すると、C# 側実装は前述のように [DisableRequestSizeLimit] 等のリミッタ解除属性を指定していても、その前段の IIS の限界値に触れて、IIS のエラーになってしまう。 IIS 側の限界値設定は、web.config ファイルをコンテンツルートフォルダに配置することで、設定変更可能だ。 具体的には下記内容の web.config ファイルを配置する。
こうすることで、試してみたところ、4GB までのファイルをアップロードすることができるようになった。 なお、上記 web.config の設定上、maxAllowedContentLength = 受信できる要求サイズの限界値は、32bit の符合無し整数値による指定が限界らしい。 すなわち、IIS 経由の場合のアップロード可能なファイルサイズは最大サイズは 4GB までということだ。 (もちろん、単純な HTTP POST x 1発ではなく、何かしらのストリーミングやチャンク分割しての送信など他の手法であればこの限界は回避できるだろうが、このトピックでは HTTP POST x 1発縛りということで。) さらなる課題...この IIS の制約をさらに緩和できるのか、IIS の (現状の "統合パイプラインモード" ではなく) "クラシックモード" だったどうなるのか、などは今のところ未確認である。 その他、実際にこのアプリを Azure Web Apps に載せたらどうなるのかも気になるところだ。 さらには、このように ASP.NET Core ランタイムによしなにお願いするだけではなく、それらランタイムの処理は迂回して、時前の C# コードでブラウザからの要求送信ストリームを扱ったらどうなるのだろう、という点も気になる。 いろいろとさらに調べたいことが山積みのままであるが、とにかく、何の工夫もない素の ASP.NET Core MVC/API コントローラースタイルのサーバー側実装であっても、属性指定してリミッタ解除するだけで、これくらいのサイズの要求処理ができるということはわかった。 引き続き、残された興味課題を消化できたら、またここで情報共有できたらいいなと思っている。 とりあえず、今回作成した ASP.NET Core プログラム一式は下記に公開してあるので、ご参考までに。 ということで、来月に続く。(続かない?)
by developer-adjust
| 2020-10-30 21:14
| .NET
|
ファン申請 |
||