Плюсы и минусы наличия выделенных пулов приложений вместо хранения веб-приложений в одном пуле приложений по умолчанию

Плюсы:

• Приложения изолированы друг от друга, если IIS не идет с ним, блокировка пула приложений удалит только приложения в этом пуле.
• Возможность запускать приложения в разных средах выполнения ASP.NET, один пул для 1.1, другой для 2.0, если необходимо
• Возможность иметь разные настройки пула приложений для более или менее важных приложений. Например, корпоративный веб-сайт в ASP.NET может захотеть завершить работу через __ минут бездействия, чтобы предотвратить выгрузку, поскольку ответ критичен. Другим сайтам это может не понадобиться.
• Могут защищать пулы друг от друга в отношении доступа к файлам, отлично подходит для сторонних или ненадежных приложений, поскольку они могут работать под очень ограничительной учетной записью пользователя.

Минусы:

• Каждый пул приложений имеет свой собственный банк памяти и собственный процесс, поэтому МОЖЕТ использовать больше ресурсов.
• Некоторым сложно отлаживать приложение, так как у вас несколько процессов.

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

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

Кроме того, если вы смешиваете версии ASP.Net на одном и том же веб-сервере, вам понадобятся разные пулы приложений для каждой версии ASP.Net как минимум или сделать это для каждого веб-сайта.

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

Я согласен с Джейсоном.

Кроме того, вы можете назначить разных пользователей (например, учетную запись Windows) для разных пулов приложений. Это позволяет настраивать этих пользователей с разными разрешениями в базе данных. Это помогает повысить безопасность и позволяет отслеживать, какой веб-сайт / пользователь обращается к базе данных, что полезно при отслеживании проблем с производительностью базы данных.

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

Например, предположим, что за ночь никто не попадет на ваш сервер, IIS будет замедляться (я полагаю, по умолчанию 20 минут). Первый человек, посетивший сервер, получит задержку, пока ваше приложение не будет загружено обратно в память.

В зависимости от того, как вы развертываете свой сайт (например, в режиме выпуска и т. Д.), Это либо не будет проблемой, либо может раздражать.

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