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

Мы запускаем приложение ASP.Net, которое также вызывает некоторые устаревшие COM-объекты. Мы сталкиваемся с проблемой, когда при увеличении количества пользователей COM-объект создает узкое место, поскольку он выполняется в том же потоке / процессе, что и пул приложений.

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

У меня есть пара вопросов.

  1. Разумно ли добавлять несколько пулов приложений, все из которых указывают на одни и те же физические файлы?
  2. Мы бы все равно использовали аппаратный балансировщик нагрузки. Все запросы, поступающие на app.xxxxxx.com, будут перенаправлены, например, на app1.xxxxxx.com, app2.xxxxxx.com, app3.xxxxxx.com, app4.xxxxxx.com. Каждый из них является пулом приложений на одном сервере. Это обычная практика?
  3. Сервер имеет 16 ядер. Имеет ли смысл устанавливать привязку процессора к выделению каждого пула приложений для работы на 4 ядрах?
  4. Мы застряли на сессиях InProc. Из-за этого мы даже не рассматриваем возможность использования Web Garden. Плюс из того, что я прочитал, Web Garden - больше для повышения доступности, чем производительности.

Я по профессии разработчик, и мне пришлось исследовать / выполнять эти задачи, и многое из этого было для меня процессом обучения.

Спасибо

Источник

1 ответ

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

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

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

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

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

Источник
Другие вопросы по тегам