Мы запускаем приложение ASP.Net, которое также вызывает некоторые устаревшие COM-объекты. Мы сталкиваемся с проблемой, когда при увеличении числа пользователей COM-объект создает узкое место, поскольку он выполняется в том же потоке / процессе, что и пул приложений.
В настоящее время у нас есть аппаратный балансировщик нагрузки, и мы используем липкие сеансы для балансировки нагрузки между двумя серверами. К сожалению, этого кажется недостаточно. Мы провели некоторое тестирование с использованием нескольких пулов приложений, каждый из которых запускает одно и то же приложение, и производительность, похоже, значительно улучшилась.
У меня есть пара вопросов.
Я разработчик по профессии, и мне пришлось исследовать / выполнять эти задачи, и многое из этого было для меня процессом обучения.
Спасибо
У вас довольно уникальная ситуация, когда COM становится узким местом, так что вы не можете просто масштабироваться. В идеале повышение производительности с помощью COM-объектов или их замена управляемым кодом могло бы масштабироваться еще лучше, но вы на правильном пути для обходного пути производительности COM.
IIS может обрабатывать сотни пулов приложений, так что это не проблема. Он добавит несколько МБ ОЗУ для каждого пула приложений, но без дополнительных затрат на производительность.
Конечно. Под пулом приложений я предполагаю, что каждый из них представляет собой полноценный сайт со своим собственным пулом приложений. Все хорошо.
Если вам не нужно, не изменяйте привязку процессора, потому что это означает, что вам нужно поддерживать и настраивать его навсегда. Если загрузка ЦП довольно плоская, значит, вы справитесь со значениями по умолчанию. Если у вас есть другие приложения на сервере или вы видите большой дисбаланс, подумайте о сходстве процессора. IIS хорошо справляется с их использованием по большей части, поэтому по возможности лучше позволить ему выполнять тяжелую работу.
Как вы говорите, это решает липкая сессия, так что у вас все хорошо. Веб-сады могли решить ваши проблемы с COM, если бы вы не беспокоились о состоянии сеанса InProc. В качестве стороны вы можете рассмотреть возможность использования сервера состояний ASP.NET. Пусть каждый сервер использует локальный сервер состояний, а балансировщик нагрузки - липкие сеансы с 1 привязкой на сервер. Это будет касаться состояния сеанса (при условии, что все сериализуется, что обычно происходит), и позволит вам легко играть с настройками веб-сада без необходимости возиться с балансировщиком нагрузки.