Лучший дизайн для длительного процесса в веб-сервисе

Question

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

На высоком уровне этот процесс в настоящее время является следующим

Client

1. Пользователь запускает новый запрос через веб-службы вызова из приложения клиент/сервер
2. запроса и задачи, созданные и сохраненные в база данных.
3. Создана новая тема, которая начинает обработку запроса
4. Идентификатор запроса, возвращенный клиенту (опросы клиентов с использованием идентификатора).

Thread

1. Грузы до запроса деталей и несколько задач
2. Для каждой задачи он запрашивает XML через другую службу (примерно 2 сек ожидания)
3. Передает XML в другую службу для обработки (около 3 секунд ожидания)
4. Повторите попытку до завершения всех заданий
5. Запрашиваемая метка завершена (клиент будет знать свое завершение)

В целом это занимает приблизительно 30 секунд для запроса 6 задач. Поскольку каждая задача выполняется последовательно, она явно неэффективна.

Было бы лучше разбить каждую задачу снова на отдельном потоке, а затем, когда все они будут полностью отмечены, запрос будет завершен?

Мое предложение состоит в том, что я немедленно дублирую количество потоков на 6-10 (количество задач) и обеспокоен тем, как это повлияет на IIS. По моим оценкам, я мог бы сократить нормальный 30-секундный звонок до 5 секунд, если бы у меня была обработка каждой задачи одновременно, но под нагрузкой этот дизайн страдал?

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

Это просто плохой дизайн, и если есть лучший подход? В настоящее время я ограничен текущей версией DotNet.

Благодаря

Answer 1

Если вы беспокоитесь о производительности IIS вы, вероятно, хотите, чтобы сохранить рабочие места за пределами IIS, поэтому ИМО я хотел бы рассмотреть очереди задач и создание отдельной службы, чтобы сделать работу. Такой подход был бы более масштабируемым, поскольку вы могли бы добавлять или удалять интерфейсные серверы IIS или процессоры задач для обращения к различной нагрузке. Крупномасштабная система, безусловно, будет выполнять обработку с внешнего сервера.