SharpZipLibを使用します。私たちはサーバ上のファイルを解凍して別のフォルダに置く必要があります。ファイルを解凍するリクエストは、Webページのユーザーからのものです。ファイルが十分な大きさであれば、解凍するのに時間がかかるでしょう。 サイトの閲覧を続けるために解凍が完了するのを待っている間に、ユーザーがページにこだわられないようにします。ASP.NET - サーバー上のファイルを解凍するためのWebページ要求
このシナリオを処理するには良い方法は何ですか：ファイルを解凍するために別のスレッドをスピンオフしたり、ファイルを解凍する別のWindowsサービスを作成したりします。
個別のスレッドまたはウィンドウサービスを使用して行うことの賛否両論は何ですか？
別のプロセスの利点
別のプロセスで行われる作業が時間内に切り離すことができるだけでなく、物理的、およびセキュリティの観点から、。減結合：あなたが選択した場合、負荷が低いときと余分なCPUサイクルがあるときに「後で」まで物を解凍する要求をバッファすることができます。
物理的にもデカップリングされています。大規模なシステムでは、複数の独立したマシンに配備された複数のワーカー・プロセスを持つことができ、この作業を非同期で行うことができ、その処理レイヤーはWebページの処理とは独立して拡張できます。どのシステムにもボトルネックがあり、分散配置の利点は、ボトルネックをより効率的に排除するために、別々のワークロードを個別に拡張できることです。
この後者の利点は、非常に大規模なシステムでのみ有用であると私は言うだろう。ほとんどの場合、独立した物理的スケーリング層の恩恵を受けるような種類の取引量はありません。これは、ワークブックのだけでなく、すべてのワークロードの98％に当てはまります。 YAGNIの原則はスケーラビリティにも適用されます。
物理的なデカップリングによって、異なる作業負荷（ページフローとジップアンパック）を個別に開発することもできます。言い換えると、作業項目がシンプルな「ファイルを解凍」するのではなく、複数のステップとデシジョンポイントを使用してより複雑なものであったとします。別のプロセスで作業プロセッサを設計することで、作業フローの処理とは独立してページフローを構築し、テストすることができます。彼らが独立して進化しなければならない場合、これは素晴らしい利点になるかもしれません。
この物理的デカップリングは、作業項目が異なるチャンネルを介して到着する場合にも便利です。 Webページだけで作業項目が到着する唯一の方法ではないとします。 ftpドロップ、Webサービス、またはワークアイテムを受け取ることができるマシン監視の電子メールボックスがあるとします。その場合、ワークアイテム処理を物理的にウェブページ処理から切り離すことが理にかなっています。
最後に、これらのことは実行時にセキュリティ上分離されます。Webアプリケーションサーバーの一部のデプロイメントでは、セキュリティルールによってWebサーバーがディスクへの書き込みを禁止します.Webサーバーに書き込み可能なディスク記憶域はありません。別個の非同期ワーカープロセスは、ネットワークの別個の部分に配置することができ、十分な記憶容量を有し、恐らくセキュリティ要件の別個のセットによって制約される。これはあなたには当てはまらないかもしれません。スレッド処理の
利点
は別のスレッドで作業を行うことの利点は、それがはるかに簡単であるということです。デカップリングは、複雑さとコストをもたらす。別のスレッドで作業を管理すると、別々のプロセス（潜在的に別のマシン）を管理する上での操作上のオーバーヘッドはありません。追加の構成はなく、新しいビルド/展開のステップはありません。追加のバックアップはありません。維持する追加のセキュリティIDはありません。心配する通信交換はありません（スレッドディスパッチを超えて）。
作業項目処理についてもう少し洗練されたものを選択し、zipファイルが十分に小さく見えるときにオプションで作業を同期させることもできます。応答時間が4秒のしきい値を設定したとします。これを上回ると、非同期のワークロードが必要になります.4秒未満では、「インライン」となります。もちろん、zipファイルの所要時間は決してわかりませんが、ファイルのサイズに基づいて優れたヒューリスティックを確立することはできません。この最適化は、外部処理を非同期処理に使用するのか別のスレッドを使用するのかにかかわらず可能ですが、別のスレッドを使用する場合は最適化を利用する方が簡単です。追加作業が少なくて済みます。したがって、これはスレッド化アプローチの利点です。
非差別
あなたは別のプロセスまたは別のスレッドのいずれかで動作します作業項目の状態の通知のためのAJAXのポーリングメカニズムを、持っていることを選択した場合。どのように作業項目の追跡を行うのか分かりませんが、特定の作業項目（zipファイル？）が完了したら、ファイルシステム内のファイル、データベース内のテーブル。この更新は、同じプロセス内のスレッド、または別のプロセス（Windowsサービス）によって行われているかどうかに関係なく発生します。したがって、投票するAJAXクライアントは、どのような場合でもdbテーブルまたはファイルシステムをチェックするだけで、アーキテクチャーの決定にかかわらず、同じ方法で作業項目のステータスを通知します。
理論を決定する方法
は、実際の運用上の制約なしに、興味深いが、最終的に無用です。
ワークロードは、現実世界の主要アイテムの1つです。あなたは、これらのzipファイルの大きさについては言いませんでしたが、私はそれらが "普通のサイズ"であると推測しています。何か約4GB以下。通常、そのようなzipファイルは私のラップトップで解凍するのに20〜60秒かかりますが、もちろん実際のストレージシステムとより高速なCPUを搭載したサーバーでは、それは少なくなります。また、トランザクションの並行性を特徴付けることもできませんでした。これらのトランザクションのうち、どれだけ多くのトランザクションが一度に実行されるのでしょうか。私は並行性が特に高いとは思わない。
これが当てはまる場合、私は単純な非同期スレッドアプローチに固執します。あなたはASP.NETでこれをやっている、私はサーバーのOS上で推測する。 CLRには優れたスレッド管理機能があり、ASP.NETには優れたプロセススケールアウト機能があります。したがって、高いワークロードでも、大量の構成作業を行うことなく、CPU使用率とスケーラビリティを向上させることができます。
作業項目が長時間実行されていた場合 - 数時間または数日ものオーダーで、時間が予測できない場合（在庫注文の終了など）、その場合は非同期処理に傾きます。同時実行数が1秒間に数千回であったり、予測できなかったりする場合は、別のプロセスを推奨します。障害モードが十分に複雑であれば、作業項目を管理するために作業項目を別のプロセスにしたいと思うかもしれません。作業項目の処理が定期的に変更される可能性がある場合（進化するビジネス状況に応じて追加ステップを追加する）、別のプロセスで処理することが必要な場合があります。
しかし、あなたのケースではこれらのことは真実ではないようです。別のスレッドの
個人的に私は進行状況のためにそれらの間のメッセージングを使ってWindowsサービスルートを下り、ステータスを監視するために使用できるunzipにhandleを返します。
しかし、私はおそらくそれを行うためにスレッドをスピンオフすると思うかもしれません。それはうまく実行され、ページが戻ってきます。
個別のスレッドまたはウィンドウサービスを介してそれを行うことの長所と短所は何ですか？ –
私は、AJAX対応ページから簡単にポーリングできる非同期プロセスを使用します。完了すると、ページのAJAX部分は、ユーザがプロセスが同期して完了するのを待っている間に通常提示した詳細を表示できます。ページフローから
欠点は以下のとおりです。
利点は以下のとおりです。解凍が完了したときにユーザーに通知する必要がない場合、火災を行うと、忘れて
Windowsサービスのメリットとデメリットは、上記とほぼ反対です。
興味深いビットを反映するために質問を書き直す価値があります。それは最も重要な解凍ではありません。非同期作業をインプロセスで行うのか、アウトオブプロセスで行うのかを決定する方法です。 – Cheeso