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

Question

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

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

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

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

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

Спасибо

Answer 1

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

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

http://blogs.msdn.com/pandrew

Answer 2

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

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

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

Groete, Hans

Answer 3

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

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

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

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

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