08:25:36業務用のWebアプリケーションでは、帳票出力やExcel出力といった要件はよくあると思いますが、この出力処理に何十秒もかかる(ほど出力データ量が多い)場合、ASP.NETではどのように設計するのが一般的なのでしょうか。出力要求のHTTPリクエストで、ファイル出力処理用のスレッドを作って、一旦ブラウザにHTTPレスポンスを返し、Ajax等で定期的に進捗状況を監視する・・・という方法を取っているASP.NETアプリケーションを触っているんですが、本当に大丈夫なのか疑問を感じています。ASP.NET内部でやろうとせずに、別プロセスで動作するサービスか何かを作って、帳票出力はそいつに任せるといったアプローチが一般的でしょうか。非同期プログラミングモデルを使用するという方法があります。マガジンの以下のページが、非同期プログラミングの目的、メリット、仕組みなどをサンプルコードを使って詳しく説明しており、参考になると思います。ハンドラのサンプルはかなり複雑で分かりにくいので、以下のページに簡単なサンプルを作ってみました。よろしければこちらも見てください。14:11:31バックグラウンドでスレッドを使って実行する方法は、確実性という点ではあまり高くありません。現実的には数十秒程度で終わる処理ならあまり実害はないことが多いですが、安全な方法ではありません。簡単に言うと、ASP.NET環境では、アプリケーションのライフサイクルが独自に管理されており、それのあずかり知らないところで勝手にスレッドを使って処理をしていても、それを安全に面倒見てはくれないためです。プロセスやサービスを外部に作成して別プロセスで処理させる方が、そういう意味で安全性は高まります。あと、SurferOnWwwさんが書かれている非同期処理の方法は、何と言いうか(今現在質問者さんが書かれている状況や話とは)若干観点が異なる話ですので、混乱しないように念のため補足しておきます。ASP.NETでの非同期処理(非同期ページや非同期ハンドラなど)というのは、HTTPクライアントからみると同期処理で、あくまでサーバ側でのスレッドプールを有効活用するための仕組みです。今回で言うと、ブラウザから見ればバックグラウンドで処理をさせるのではなく、ブラウザからの要求は処理が完了するまで返ってこないイメージになります。帳票の作成処理は、Webサーバとは別の帳票サーバで行うようになっており、Webサーバからは帳票サーバをさらにWebサービスとして呼び出す、という構造だったとします。IE→Webサーバ→帳票サーバこの時、Webサーバから帳票サーバを同期呼び出しすると、帳票作成処理が終わるまで、Webサーバのスレッドが待機状態になります。これでは貴重なスレッドプールのスレッドを占有してしまうため、帳票サーバを非同期呼び出しし、帳票サーバからのレスポンスが帰ってくるまでは、スレッドをいったんスレッドプールに返せるようにした仕組みが、ASP.NETにおける非同期処理(非同期ページや非同期ハンドラなど)です。このように、例えば帳票作成処理などの、時間のかかる処理が、外部リソースの非同期呼び出しとして実行できる場合のものですので、Webサーバ自身でがりがりCPUを使って処理するような場合には使えません(基本的に長いIO待ちが発生する場合用と思ってください)。上にも書きましたが、非同期ページや非同期ハンドラを呼び出す側(ブラウザ)から見ると、普通の同期呼び出しになります。質問者さんの観点は具体的にどういうことで、それとどのように異なるのでしょうか?質問者さんの観点は、なちゃさんが質問者さんに直接聞くなどして確認されたのか、それともなちゃさんの推測なのかも併記いただけますようお願いします。16:31:37?--------------出力要求のHTTPリクエストで、ファイル出力処理用のスレッドを作って、一旦ブラウザにHTTPレスポンスを返し、Ajax等で定期的に進捗状況を監視する・・・という方法を取っているASP.NETアプリケーションを触っているんですが、本当に大丈夫なのか疑問を感じています。--------------という状況で気にしていることや、長時間かかる処理をASP.NETでは一般にどのように実装するか?という事象について、ASP.NETの非同期処理はちょっと目的の観点が異なりますよね?時間のかかる処理を別サーバなどで実行して、それを呼び出しているときに、CPUが十分に活用できずスケールしない、という状況であれば非同期処理が候補に挙がってくる可能性はもちろんありますが(別にそれを否定したりしません)。普通に読めば、質問者さんが「今」気にしているのはそこではなさそうだ、というだけです。加えて、今の質問者さんは、クライアント側から見て非同期的な処理が頭にあると思われるので、ASP.NETの非同期処理を特に詳細な説明なく出すと混乱するかもしれないと思ったので補足しただけです。17:33:56質問者さんの質問に対して、なちゃさんと自分とで着目しているところが違うだけだと思います。【なちゃさん】(今のやり方で)本当に大丈夫なのか疑問。非同期プログラミングモデルを使用するという方法があります。23:59:19すみません、私の説明不足でした。元々の質問内容が「どのような設計が一般的か」「今私が触っているアプリの設計は問題無いのか」ですので、どのような観点からの指摘でも助かります。これは私が明示しておらず申し訳ないのですが、なちゃ様が指摘されているように、「HTTPクライアントからみると同期処理」となると、何十秒もかかる処理では問題となります。ここでいくつか疑問がわきましたので、続けて質問させて下さい。観点は、SurferOnWww様に提示して頂いた非同期ハンドラが目的としている、スレッドプールの飽和に関してです。質問Aの1と2がいずれもスレッドプール飽和対策になっており、スレッドプールの飽和だけを問題視するのであれば、2よりも1の方が実装が簡単なので、優れています。あるとしたとき、HTTPクライアントからも非同期に見える(できれば毎秒HTTPリクエストを投げて進捗を監視したい)ようにする場合、非同期ハンドラを使うメリットはあるのでしょうか。01:42:55こんにちは。アプリケーションデザインとしての方法・問題2)システム(アプリケーション)デザインとしての方法・問題どちらについて、より関心があるのか?が不明であるという事でした。両方を同時にとなると、色々発散していくのではないかなと思いました。次に、「本当に大丈夫なのか疑問を感じています」ということで、この不安をもう少し掘り下げ、不安が何に起因しているのか?を考える必要もあるのかなと思います。・利用者が「待つ」事自体の是非、要件から見てどうなのか。「何十秒も待つ」事の何が問題なのか?・現在の仕組みが、トラフィックやサーバーリソースを考えた場合、許容範囲はどの程度になりそうか。・レスポンスが帰ってくるまでに、30秒待つ・レスポンスはすぐに帰ってくるが、30秒間刻々と進捗が表示される。結果的に、処理結果の完了を期待し、利用者は待ってしまう?といった事もありえます。「実は15分待つ処理があり、以外に利用される」といった場合は、進捗表示自体の意味(や方法)を問われる可能性もあります。「即座に別のオペレーションに取り掛かれる事」という要件があった場合、利用者の注意を引く進捗状況の表示は是か非か、といった事もアーキテクチャ(やテクノロジ)選択する上で必要になるのではないかなと思います。このあたりは、「ASP.NET内部でやろうとせずに、別プロセスで動作するサービスか何かを作って、帳票出力はそいつに任せるといったアプローチが一般的でしょうか」に掛かってくる可能性があります。・要件を満足しているのか?(うまく業務に専念できるデザインなのか)・テクノロジーとしての問題を何か抱えているのか?・リソースに余裕はどの程度あるのか?・将来的に、環境変動(トラフィック等)があった場合、どの程度満足できるのか?・仕組みの変更(別プロセスでの処理等の採用)等があった場合に、どの程度容易に変更できるのか?・その他などを整理してみるという事も必要かもしれません。使うそうなので、飽和対策にはなっていないと思います。理由も書いてあるので読んでください。ような方法は、なちゃさんの言われるように、好ましくないと自分も思います。以下のようなページを見つけましたが、個人的にはその意見に納得してます。さんの言われるように、要件の整理など原点に立ち戻ってシステムのデザインを再検討したほうがよさそうな気がします。12:06:09ASP.NETでの非同期処理の仕組み(非同期ハンドラや非同期ページ)は、「非同期のワーク」をASP.NET上で効率よく扱うための仕組みです。そのしくみがうまく動作するためには、対象となる「非同期のワーク」がIOバウンドであることが重要です。Applications」とあるように、この話は、「非同期のワーク」が前提としてあり、それを効率よく実行するには、ASP.NETの非同期の仕組み(非同期ハンドラや非同期ページ)を使いなさいということです。「長時間かかる処理は非同期で実行しなさい」ではありません。CPUバウンドの処理を、非同期化しても効率は悪化するだけです。時間のかかる処理が別のWebサービス呼び出しなど、IOバウンドの処理であれば、非同期化すると効率化できる可能性はあります。ASP.NETの非同期のしくみは長時間処理の解決策そのものではありません(長時間処理を、特定の方法で実装している場合に、それを効率的に処理できる手法ではありますが)。ASP.NETで長時間処理を行う場合は、一般的に非同期の仕組みを使うというものではありません(繰り返しますが、長時間処理の実装方式によっては、これが有効な場合ももちろんあります)。いう辺りを質問者さんが誤解するとまずいので、念のため補足しておきます。00:52:30皆さんありがとうございます。非同期ハンドラ、というものに対してもやもやしていたものがようやく晴れてきました。※なちゃ様の補足が助かりました。混乱していたポイントです。原理が分かればあとは要件との相談次第ですね。対して渡されたディレクトリは空です。flyppdevportal.com.。