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

Question

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

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

Хорошая практика создания отдельных пулов приложений для каждого приложения?

Answer 1

из ServerFault Повторно "Why add additional application pools in IIS?"

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

Answer 2

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

Answer 3

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

У меня было 58 веб-сайтов .Net и 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 - отличная идея по многим причинам, упомянутым в других сообщениях выше, но это также по моему опыту вызывает гораздо более высокие издержки памяти, если вы размещаете большое количество сайтов на одном сервере.

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