Длинные рабочие процессы в Sharepoint, блокируют ли они процесс w3wp

Question

У нас есть установка WSS 3.0 с Search Server, которая используется для поиска документов и сохранения определения поиска, чтобы повторить поиск позже. Пользователи хотят, чтобы опция могла загружать все файлы в результатах поиска в виде одноразового Zip-файла.

У меня есть очень простое решение, где Zipping файлов выполняется в веб-части, когда пользователь нажимает кнопку, но если zip-файл занимает некоторое время, чтобы создать пользователя, остается ждать (и я подозреваю, любые другие пользователи, получающие доступ к сайту, будут ждать, потому что я думаю, что сжатие документов выполняется процессом w3wp).

Я подумал, что, возможно, я мог бы начать создание zip-файла в качестве рабочего процесса, и пользователю будет разрешено загрузить файл после завершения рабочего процесса, но теперь я понял, что рабочие процессы также выполняются в процессе w3wp.

Если задача рабочего процесса занимает много времени (если, например, пользователь выбрал большое количество документов для загрузки), это повлияет на других пользователей сайта sharepoint и остановит их доступ к любым страницам до тех пор, пока рабочий процесс завершено?

Очевидно, мы собираемся установить ограничение на максимальный размер документов, которые пользователь может закрепить для загрузки, чтобы мы не убивали машину, но я все еще беспокоюсь о том, что какой бы ни был лимит, рабочий процесс процесс может по-прежнему блокировать других пользователей. В этом случае? Есть ли какие-нибудь лучшие предложения для создания такой задачи, которая не повлияет на других пользователей?

Благодаря

Answer 1

Помещенной активность задержки в рабочем процессе до начала деятельности, что делает создание ZIP. Это заставит рабочий процесс от интерактивного процесса W3WP до сервиса WSSTimerV3, так как он должен запускаться в будущем.

С уважением, Пол

http://blogs.msdn.com/pandrew

Answer 2

Даже когда вы делаете молнию в веб-части, вы не блокирует других пользователей. Рабочий поток w3wp, обрабатывающий запрос, был заблокирован, ожидая завершения zip, но все остальные рабочие потоки были в состоянии продолжить.

Тем не менее это может стать проблемой масштабируемости, если было много ожидающих zip-потоков: в конечном итоге входящие запросы могли блокировать ожидание появления рабочих потоков. Это причина использования асинхронной обработки в ASP.NET.

Использование рабочего процесса помогло бы, поскольку рабочий процесс был запущен, и запрос завершен, разрешив обработку других запросов.

Вас беспокоил рабочий процесс, запущенный в w3wp. Тем не менее, я не знаю, что он работал на одном из рабочих потоков в w3wp. Я не знаю, как SharePoint настраивает хост рабочего процесса, но я подозреваю, что он использует другой набор потоков.

Возможно, вы захотите провести нагрузочное тестирование этого, чтобы узнать это. Создайте фиктивную веб-часть, которая просто запускает ZIP, как только вы запрашиваете страницу, содержащую ее. Запустите загрузку на эту страницу и узнайте, сколько запросов вы можете получить, прежде чем они начнут стоять в очереди, ожидая появления рабочих потоков. Затем сделайте то же самое, но веб-часть начнется с рабочего процесса. Опять же, посмотрите, сколько запросов вы можете запустить одновременно, прежде чем запросы начнут стоять в очереди.

Answer 3

1. Если задержка составляет менее 5 секунд, я бы просто сделал это синхронно в том же потоке и делал с ней. Наименьшая сложность, лучший пользовательский интерфейс, отсутствие блокировки других пользователей (ограничен размером пула потоков ASP.NET). Однако куча кликов убьет сервер.

2. Если у вас есть большие файлы или много трафика, вы можете сохранить очередность в базе данных и получить сервис Windows, чтобы выполнить их. Таким образом, вы контролируете количество потоков, используемых для zip-файлов. Это решение дает вам алгоритмическую сложность O (1), но значительно увеличивает сложность конструкции. Вы можете захотеть использовать что-то вроде AJAX, чтобы рассказать пользователю «Вы в 4 из 45 в очереди ...».

3. Если у вас есть большой выбор размеров файлов, вы можете реализовать два лучших решения в качестве стратегий и реализовать третью адаптивную стратегию, которая отходит от одной из вышеупомянутых стратегий, рассматривая такие вещи, как распакованный размер и сервер доступность ресурсов. Хороший компромисс между пользовательским опытом и доступностью ресурсов, но самый сложный (дорогой).

Groete, Ханс