SharpZipLibを使用します。サーバー上のファイルを解凍して、別のフォルダーに配置できる必要があります。ファイルを解凍する要求は、Web ページ上のユーザーからのものです。ファイルが十分に大きい場合、解凍に時間がかかると思います。サイトの閲覧を続行するために、解凍が完了するのを待っている間、ユーザーがページにとどまることは望ましくありません。
このシナリオを処理する適切な方法は何ですか: ファイルの解凍を処理するために別のスレッドをスピンオフするか、ファイルを解凍する別の Windows サービスを作成するか、または ....何ですか?
別のスレッドまたはウィンドウ サービスを介してそれを行うことの長所と短所は何ですか?
別のプロセスの利点 別のプロセス
で行われる作業は、時間的にも物理的にも分離でき、セキュリティの観点からもページ フローから切り離すことができます。時間の分離: 必要に応じて、負荷が低くなり、CPU サイクルに余裕がある "後で" 解凍する要求をバッファリングできます。
また、物理的に切り離されています。大規模なシステムの場合、複数の独立したマシンにデプロイされた複数のワーカー プロセスを使用して、この作業を非同期で行うことができ、その処理レイヤーは Web ページ処理とは独立してスケーリングできます。どのシステムにもボトルネックはあります。分散展開の利点は、個別のワークロードを個別にスケーリングして、より効率的にボトルネックを解消できることです。
ただし、この後者の利点は、非常に大規模なシステムでのみ役立つと言えます。ほとんどの場合、独立した物理スケーリング レイヤーの恩恵を受けるような種類のトランザクション ボリュームはありません。これは、ワークロードだけでなく、すべてのワークロードの 98% に当てはまります。YAGNI の原則はスケーラビリティにも適用されます。
物理的な分離により、異なるワークロード (ページ フローと zip のアンパック) を個別に開発することもできます。言い換えれば、作業項目が単純な「ファイルの解凍」ではなく、途中で複数のステップと決定ポイントを伴う、より複雑なものであると仮定します。ワーク プロセッサを別のプロセスで設計すると、ページ フローをワークアイテムの処理とは別に構築およびテストできます。独立して進化する必要がある場合、これは大きな利点となります。
この物理的な分離は、作業項目が異なるチャネルを介して到着する場合にも役立ちます。作業項目が到着する唯一の方法が Web ページではないとします。ftp ドロップ、Web サービス、またはワークアイテムも受信できるマシンで監視される電子メール ボックスがあるとします。その場合、ワークアイテムの処理を Web ページの処理から物理的に切り離すことが理にかなっています。
最後に、これらは実行時のセキュリティで分離されます。一部の Web アプリケーション サーバーの展開では、セキュリティ ルールにより、Web サーバーによるディスクへの書き込みが禁止されています。Web サーバーには、書き込み可能なディスク ストレージがありません。別の非同期ワーカー プロセスをネットワークの別の部分に展開できます。十分なストレージがあり、別の一連のセキュリティ要件によって制約される可能性があります。これは、あなたに当てはまる場合と当てはまらない場合があります。
スレッド化処理
の利点 別のスレッドで作業を行う利点は、作業がはるかに簡単になることです。デカップリングは、複雑さとコストをもたらします。作業を別のスレッドで管理すると、別のプロセス (場合によっては別のマシン) を管理する運用上のオーバーヘッドがなくなります。追加の構成や、新しいビルド/デプロイの手順はありません。追加のバックアップはありません。維持する追加のセキュリティ ID はありません。心配する通信交換はありません (スレッドディスパッチ以外)。
作業項目の処理についてもう少し洗練されたものにすることを選択し、必要に応じて、zip ファイルが十分に小さいと思われるときに同期的に作業を行うことができます。4 秒の応答時間のしきい値を設定するとします。それを超えると非同期ワークロードが必要になり、4 秒未満の場合は「インライン」で実行されます。もちろん、zipfile にかかる時間を確実に知ることはできませんが、ファイルのサイズに基づいて適切なヒューリスティックを確立することはできます。この最適化は、非同期作業に外部プロセスを使用する場合でも、別のスレッドを使用する場合でも利用できますが、正直なところ、別のスレッドを使用する場合に最適化を利用する方が簡単です。追加作業が少なくなります。したがって、これはスレッド化されたアプローチの利点です。
非差別化
要因 ワークアイテムのステータスを通知するために AJAX ポーリング メカニズムを使用することを選択した場合、それは別のプロセスまたは別のスレッドで機能します。作業項目の追跡をどのように行うかはわかりませんが、特定の作業項目 (zip ファイル?) が完了すると、ファイルシステム内のファイル、データベース内のテーブルなど、どこかでレコードを更新すると思います。 . その更新は、同じプロセス内のスレッドによって行われているか、別のプロセス (Windows サービス) によって行われているかに関係なく発生します。したがって、ポーリングする AJAX クライアントは、どのような場合でも db テーブルまたはファイルシステムをチェックするだけで、アーキテクチャの決定に関係なく、同じ方法で作業項目のステータスの通知を受け取ります。
決定方法
理論は興味深いものですが、実際の運用上の制約がなければ、最終的には役に立ちません。
ワークロードは、重要な実世界の項目の 1 つです。これらの zip ファイルのサイズについては言及されていませんが、「通常のサイズ」であると推測しています。約4GB以下です。通常、このような zip ファイルは、私のラップトップで展開するのに 20 ～ 60 秒かかりますが、もちろん、実際のストレージ システムとより高速な CPU を備えたサーバーでは、それよりも短くなります。また、トランザクションの同時実行性についても特徴付けていませんでした。これらのうち、一度にいくつのことが発生するかということです。同時実行性は特に高くないと思います。
その場合は、より単純な非同期スレッドのアプローチに固執します。あなたはこれをASP.NETで行っています.サーバーOSであると思います. CLR には優れたスレッド管理機能があり、ASP.NET には優れたプロセス スケールアウト機能があります。そのため、ワークロードが高い場合でも、大量の構成作業を行わなくても、CPU の使用率とスケーリングが向上します。
作業項目がより長く実行されている場合 (たとえば、数時間または数日のオーダーであり、時間が予測できない (株式注文のクローズなど)) 場合は、非同期プロセスに傾倒します。同時実行が 1 秒あたり数千の場合、または非常に予測不可能な場合も、別のプロセスが推奨されます。障害モードが十分に複雑な場合は、ワークアイテムを管理するためだけに別のプロセスに入れたいと思うかもしれません。ワークアイテムの処理が定期的に変更される可能性が高い場合 (進化するビジネス状況に応じて、追加のステップを追加する)、別のプロセスに入れたいと思うかもしれません。
しかし、あなたの場合、それらのどれも真実ではないようです-zipファイルを解凍します。
別のスレッドの欠点は次のとおりです。
別のスレッドの利点は次のとおりです。
Windows サービスの長所と短所は、上記のほぼ逆です。
handle個人的には、状態を監視するために使用できる unzip に戻すなど、進行状況についてそれらの間でメッセージングを行いながら、Windows サービス ルートをたどります。
ただし、スレッドをスピンオフしてそれを実行することもできます。それは問題なく実行され、ページが返されます。
AJAX 対応ページから簡単にポーリングできる非同期プロセスを使用します。完了すると、ページの AJAX 部分は、プロセスが同期的に完了するのをユーザーが待っている間に通常表示される詳細を表示できます。