Назад | Перейти на главную страницу

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

Мы запускаем приложение 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 больше предназначен для повышения доступности, чем для повышения производительности.

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

Спасибо

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

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

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

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

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