Преимущества отдельного процесса
Работу, выполненную в отдельном процессе, можно отделить во времени, а также физически и с точки зрения безопасности от потока страниц. Разъединено во времени: если вы выберете, вы можете буферизовать запросы на распаковку, пока «позже», когда нагрузка будет ниже, и когда у вас есть запасные циклы ЦП для этого.
Также отделен физически; для крупномасштабной системы вы можете иметь несколько рабочих процессов, даже развернутых на нескольких независимых машинах, выполняющих эту работу асинхронно, и этот уровень обработки может масштабироваться независимо от обработки веб-страницы. В любой системе существуют узкие места, и преимущество распределенных развертываний состоит в том, что вы можете независимо масштабировать отдельные рабочие нагрузки для более эффективного устранения узких мест.
Я бы сказал, что это последнее преимущество полезно только в очень очень крупных системах. В большинстве случаев у вас не будет такого объема транзакций, который получал бы пользу от независимого физического уровня масштабирования. Это относится не только к вашей рабочей нагрузке, но и к 98% всех рабочих нагрузок. Принцип YAGNI применим и к масштабируемости.
Физическая развязка также позволяет независимо разрабатывать разрозненные рабочие нагрузки (поток страниц и распаковка). Другими словами, предположим, что рабочий элемент не был простым «распаковать файл», а был чем-то более сложным, с несколькими шагами и точками решения на этом пути. Проектирование рабочего процессора в отдельном процессе позволяет создавать и тестировать поток страниц независимо от обработки рабочего элемента. Это может быть хорошим преимуществом, если они должны развиваться независимо.
Эта физическая развязка также хороша, если рабочие элементы будут поступать по разным каналам. Предположим, что веб-страница - не единственный способ получения рабочей позиции. Предположим, у вас есть FTP-сервер, веб-служба или почтовый ящик, контролируемый компьютером, который также может получать рабочие элементы. В этих случаях имеет смысл физически отделить обработку рабочего элемента от обработки веб-страницы.
Наконец, эти вещи разъединены в безопасности во время выполнения. В некоторых развертываниях серверов веб-приложений правила безопасности запрещают веб-серверу выполнять запись на диск - веб-серверы не имеют доступного для записи дискового хранилища. Отдельный асинхронный рабочий процесс может быть развернут в отдельной части сети с большим объемом памяти, и, возможно, он ограничен отдельным набором требований безопасности. Это может или не может быть применимо к вам.
Преимущества резьбовой обработки
Преимущество выполнения работы в отдельном потоке состоит в том, что это намного проще. Разделение вводит сложность и стоимость. Управляя работой в отдельном потоке, у вас нет никаких накладных расходов на управление отдельным процессом, возможно, отдельной машиной. Там нет дополнительной конфигурации, нет нового этапа сборки / развертывания. Нет дополнительной резервной копии. Не требуется дополнительная идентификация безопасности. Не нужно беспокоиться об обмене данными (кроме отправки потоков).
Вы можете выбрать немного более сложную обработку рабочих элементов и, при желании, выполнять работу синхронно, когда zip-файл выглядит достаточно маленьким. Предположим, вы устанавливаете порог времени отклика 4 секунды - выше этого вам нужна асинхронная рабочая нагрузка, ниже 4 секунд вы делаете это «встроенным». Конечно, вы никогда не знаете наверняка, сколько времени займет zip-файл, но вы не могли бы установить хорошую эвристику, основанную на размере файла. Эта оптимизация доступна вам независимо от того, используете ли вы внешний процесс для асинхронной работы или отдельный поток, но, честно говоря, проще использовать преимущества оптимизации при использовании отдельного потока. Меньше дополнительной работы. Так что это преимущество для многопоточного подхода.
Без дифференциаторов
Если вы решите использовать механизм опроса AJAX для уведомления о состоянии рабочего элемента, это будет работать либо с отдельным процессом, либо с отдельным потоком. Я не знаю, как вы будете выполнять отслеживание рабочего элемента, но я полагаю, что когда определенный рабочий элемент (zip-файл?) Будет завершен, вы где-нибудь обновите запись - файл в файловой системе, таблицу в базе данных. , Это обновление происходит независимо от того, выполняется оно потоком в том же процессе или отдельным процессом (служба Windows). Таким образом, клиент AJAX, который опрашивает, в любом случае просто проверит таблицу или файловую систему БД и получит уведомление о состоянии рабочего элемента таким же образом, независимо от вашего архитектурного решения.
Как решить
Теория интересна, но в конечном счете бесполезна, без реальных эксплуатационных ограничений.
Рабочая нагрузка является одним из ключевых элементов реального мира. Вы не сказали, насколько велики эти zip-файлы, но я предполагаю, что они «обычного размера». Что-то около 4 ГБ или меньше. Обычно такой zip-файл распаковывается на моем ноутбуке за 20-60 секунд, но, конечно, на сервере с реальной системой хранения и более быстрым ЦП это будет меньше. Вы также не охарактеризовали параллелизм транзакций - сколько из этих вещей будет происходить одновременно. Я предполагаю, что параллелизм не особенно высок.
Если это так, я бы придерживался более простого подхода асинхронного потока. Вы делаете это в ASP.NET, я полагаю, на серверной ОС. CLR имеет хорошее управление потоками, а ASP.NET обладает хорошими возможностями масштабирования процессов. Таким образом, даже при высокой рабочей нагрузке вы получите хорошую загрузку и масштабируемость процессора без огромных усилий по настройке.
Если бы рабочие элементы работали дольше - скажем, порядка часов или даже дней, а время было непредсказуемым (например, закрытие ордера на покупку) - хорошо, в этом случае я бы склонялся к асинхронному процессу. Если параллелизм был в тысячах в секунду или, опять же, очень непредсказуем, это также рекомендовало бы отдельный процесс. Если режимы сбоев были достаточно сложными, я бы хотел, чтобы рабочие элементы были в отдельном процессе, чтобы просто управлять им. Если обработка рабочего элемента, вероятно, будет регулярно меняться (добавляя дополнительный шаг в соответствии с меняющимися условиями ведения бизнеса), я мог бы захотеть сделать это в отдельном процессе.
Но ни одна из этих вещей не кажется вам верной - распаковка zip-файлов.