Отдельные пулы приложений для приложений ASP.net в IIS

Ответ 1

Отправлено с ServerFault, Зачем добавлять дополнительные пулы приложений в IIS?"

• AppPools может работать как разные идентификаторы, поэтому вы можете ограничить права доступа таким образом.
• Вы можете назначить различную идентификацию для каждого пула приложений, чтобы при запуске диспетчера задач вы знали, какой именно w3wp.exe является.
• Вы можете повторно использовать/перезапустить один пул приложений, не затрагивая сайты, запущенные в разных пулах приложений.
• Если у вас есть веб-сайт с утечкой памяти или, как правило, неправильная работа, вы можете поместить его в пул приложений, чтобы он не влиял на другие веб-сайты.
• Если у вас есть сайт с очень интенсивным процессором (например, изменение размера фотографий), вы можете разместить его в своем собственном пуле приложений и отключить его использование ЦП.
• Если у вас есть несколько веб-сайтов, каждая из которых имеет свою собственную базу данных SQL, вы можете использовать аутентификацию активного каталога вместо хранения имен пользователей/паролей в web.config.

Ответ 2

Раньше у меня было 58 веб-сайтов и 17 старых классических веб-сайтов ASP на одном сервере IIS7.5 с использованием отдельных пулов приложений для каждого сайта. Я заметил, что сжатие IIS начало прерываться с перерывами, в результате чего таблицы стилей были повреждены примерно в 5% случаев. Глядя на задачу mamanger на сервере, я мог видеть, что сервер приближается к нему с ограничением по 4 ГБ. Каждый процесс w3wp.exe берет что-то до 100 МБ памяти в зависимости от того, сколько трафика он получает. Затем я переместил все веб-сайты в 2 пула приложений (один для веб-сайтов .net 4 и один для старых классических сайтов ASP), а общая память, используемая после этого, снизилась с 3,8 ГБ до чуть менее 2,8 ГБ - сэкономила мне более 1 ГБ памяти пространства на сервере. После изменения (и оставление сервера на пару часов, чтобы вернуться к нормальному уровню трафика), процессы w3wp использовали 300 МБ для всех веб-сайтов .net и 20 МБ для классических веб-сайтов ASP. Я могу снова включить сжатие IIS без проблем.

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

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

Ответ 3

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

Приложения с использованием того же доступа, версия .NET и т.д. будут работать более эффективно в одном пуле и будут более легко поддерживаться. Наиболее раздражающе, IIS будет убивать пустые пулы приложений, требуя, чтобы пул воссоздавался при каждом использовании. Если вы изолируете редко используемые приложения, вы накладываете ненужные затраты на запуск для пользователей. Объединение этих приложений в один пул сделает для более счастливых пользователей, когда они не платят стартовые затраты, более счастливые серверы, когда они не дают памяти нескольким процессам и кускам ЦП для них, и более счастливым администраторам, когда им приходится управлять меньшим количеством приложений бассейны.

Ответ 4

да, это хорошая идея даже для 20 приложений.

• Безопасность. Различные пулы приложений, запущенные под разными учетными записями.
• Изоляция. Одно аварийное приложение не будет удалять другие приложения.
• Память (если вы используете 32 бит). Каждый пул приложений будет иметь собственное адресное пространство. Таким образом, вы можете адресовать гораздо больше памяти, чем максимум около 2,7 ГБ полезного пространства для 1 процесса.
• Вы можете периодически перезапускать одно приложение не очень хорошо, не затрагивая другие приложения.

Ответ 5

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

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

• Используйте отдельные пулы приложений, если каждому приложению нужен другой доступ к системным ресурсам. (Можно использовать несколько учетных записей процессов)
• Если приложение является ресурсом hog, критически важным или "неизвестным", лучше всего включить его в свой собственный пул, чтобы изолировать его от остальной системы.