Вертикальная масштабируемость с несколькими пулами приложений

У Вас есть довольно уникальная ситуация, где COM становится узким местом так, чтобы Вы не могли просто увеличиться. Идеально улучшающая производительность с COM-объектами или замена их с управляемым кодом масштабировались бы еще лучше, но Вы на правильном пути для обходного решения производительности COM.

1. IIS может обработать сотни пулов приложений, таким образом, это не проблема. Это добавит некоторых МБ RAM с каждым пулом приложений, но никакой дополнительной производительностью наверху.

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

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

4. Как Вы говорите, липкие адреса сессий это, таким образом, Вы хороши. Веб-сады, возможно, решили Ваши проблемы COM, если у Вас не было состояния сеанса InProc для волнения о. Как сторона, можно рассмотреть использование сервера ASP.NET состояния. Имейте каждый сервер, используют локальный сервер состояния и имеют липкие сессии использования подсистемы балансировки нагрузки с 1 привязкой на сервер. Это обратилось бы к состоянию сеанса (как долго, как все сериализирует, который оно обычно делает), и оно позволит Вам легко играть с веб-настройками сада, не имея необходимость смешивать с подсистемой балансировки нагрузки.