Классический жерех - длительные процессы. Причины, почему это плохо? - PullRequest
3 голосов
/ 17 февраля 2012

Я унаследовал очень старый классический сценарий ASP, который использовался для отправки электронных писем примерно от 5000 до 10000 получателям одновременно, причем партиями по несколько сотен. Он находится на выделенном сервере с веб-сайтом с высоким трафиком.

Свойство server.scripttimeout для почтового сценария установлено в 10 минут, и весь список рассылки загружается в память в scripting.dictionary, который используется для проверки электронной почты и удаления дубликатов.

Этот сценарий может потенциально использоваться от 10 до 20 человек одновременно, каждый из которых отправляет до 10 почтовых снимков каждый.

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

Кто-нибудь может дать какие-либо технические причины, почему это не очень хорошая идея? Я считаю, что этот скрипт должен быть заменен почтовым сервером, но мне нужны технические причины, чтобы процитировать.

Любые комментарии приветствуются.

Best, Jack


Редактировать

В частности, я думаю, что каждый раз, когда запускается этот скрипт, поток из пула потоков ASP будет занят рассылкой.

Согласно http://www.iis.net/ConfigReference/system.webServer/asp/limits, свойство processorThreadMax:

"Атрибут processorThreadMax указывает максимальное количество Рабочие потоки на процессор, которые может создать IIS.

Примечание. Этот параметр может существенно повлиять на масштабируемость вашего Веб-приложения и производительность вашего сервера в целом. Поскольку этот атрибут определяет максимальное количество запросов ASP, которые может выполняться одновременно, этот параметр должен оставаться по умолчанию значение, если ваши приложения ASP не выполняют расширенные вызовы внешние компоненты. "

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

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

Кто-нибудь может подтвердить, если я прав?

1 Ответ

1 голос
/ 17 февраля 2012

Несколько причин для рассмотрения:

Что если вы перезагрузите пул служб / приложений IIS во время обслуживания веб-сайта?

Что если ваш почтовик будет использовать огромное количество ресурсов?

Что, если какая-то другая страница будет потреблять огромное количество ресурсов (что мешает вашей почтовой программе работать правильно)?

PS: А как вы теперь запускаете свой скрипт? Если вы делаете это, переходя на определенную страницу в браузере, вы должны также рассмотреть причины обслуживания: браузер может отменить запрос по тайм-ауту, и, хотя вы можете обойти различные проблемы, которые возникают (IIS отменяет выполнение скрипта , неудобное ведение журнала), это все еще добавляет к куче недостатков.

...