3

WSS 3.0 がインストールされており、検索サーバーを使用してドキュメントを検索し、後で検索を繰り返すために検索定義を保存します。ユーザーは、検索結果のすべてのファイルを 1 回限りの Zip ファイルとしてダウンロードできるオプションを望んでいます。

ユーザーがボタンをクリックしたときにファイルの圧縮が Web パーツで行われるという非常に基本的なソリューションがありますが、zip ファイルの作成に時間がかかる場合、ユーザーは待機状態になります (そして、他のユーザーがアクセスしていると思われます)。ドキュメントの圧縮が w3wp プロセスによって行われていると想像するため、サイトは待機します)。

代わりにワークフローとして zip ファイルの作成を開始し、ワークフローが完了したらユーザーがファイルをダウンロードできるようにすることもできると思いましたが、ワークフローは w3wp プロセスでも実行されることに気付きました。

ワークフロー タスクの実行に時間がかかる場合 (たとえば、ユーザーがダウンロードするドキュメントを大量に選択した場合)、sharepoint サイトの他のユーザーに影響を与え、ワークフローが完了するまでどのページにもアクセスできなくなりますか?

明らかに、ユーザーが圧縮してダウンロードできるドキュメントの最大サイズに何らかの制限を設けて、マシンを停止させないようにしますが、どのような制限を設けても、ワークフロー プロセスが終了する可能性があるのではないかと心配しています。他のユーザーをロックアウトします。これは事実ですか?他のユーザーに影響を与えないようなタスクを作成するためのより良い提案はありますか?

ありがとう

4

3 に答える 3

0

Web パーツで zip を実行しているときでも、他のユーザーをブロックしていませんでした。リクエストを処理した w3wp ワーカー スレッドは、zip が完了するのを待ってブロックされましたが、他のすべてのワーカー スレッドは続行できました。

それでも、zip を待機中のスレッドが多数ある場合、これはスケーラビリティの問題になる可能性があります。最終的には、ワーカー スレッドが使用可能になるのを待って着信要求がブロックされる可能性があります。これが、ASP.NET で非同期処理を使用する理由です。

ワークフローが開始され、リクエストが完了し、他のリクエストを処理できるようになったため、ワークフローを使用すると役に立ちます。

w3wp で実行されているワークフローについて懸念していました。ただし、w3wp 内のワーカー スレッドの 1 つで実行されていたかどうかはわかりません。SharePoint がワークフロー ホストをどのように構成するかはわかりませんが、別のスレッド セットを使用していると思われます。

これを確認するために、負荷テストを実行することをお勧めします。zip を含むページを要求するとすぐに zip を実行するダミーの Web パーツを作成します。そのページへのロードを実行し、ワーカー スレッドが使用可能になるのを待ってキューに入る前に取得できるリクエストの数を調べます。次に、同じことを行いますが、Web パーツでワークフローを開始します。繰り返しますが、リクエストが待ち行列に入る前に同時に実行できるリクエストの数を確認してください。

于 2009-06-20T15:27:43.547 に答える