У меня проблема с балансировкой нагрузки. Мы разработали веб-приложение для почти 1500 пользователей. Поскольку количество пользователей увеличилось, мы не можем своевременно обслуживать запросы. Загрузка страницы занимает от 10 до 20 секунд. При большой нагрузке отображение страницы может занять одну минуту.
Нам нужно решить эту ситуацию, чтобы каждый запрос обрабатывался за 2 или 3 секунды.
Хм, серьезно, вы смотрите на проблемы с совершенно неправильной стороны. Пока нет необходимости переходить на несколько серверов.
Windows server 2008 8 ГБ ОЗУ 1 МБ / с ширина полосы пропускания
Хорошо, давайте на мгновение проигнорируем нехватку памяти.
Полоса пропускания 1мбит - это жалко. Точка. 1500 пользователей параллельно перегружают полосу пропускания. Я уверен, что при проверке вы обнаружите, что проблема не в процессоре, памяти и диске, а в вашей пропускной способности.
Размещение нескольких веб-серверов с балансировкой нагрузки за линией 1 Мбит не изменит этого.
Обновление линии означает, что ваш сервер может обслуживать больше без необходимости в дополнительном оборудовании.
Получите надлежащую пропускную способность, и все будет хорошо. 1 Мбит в наши дни действительно мало. На самом деле он ВСЕГДА был низким для сервера с 1500 параллельными пользователями. Никогда не работал. Сервер сегодня должен быть как минимум на 8-мегабитном канале, профессионально больше на 34+ мегабитном канале. Хостинговые серверы технически не предлагают меньше 100 Мбит / с.
Если проблема в деньгах, знайте, что вы полностью исправляете не ту вещь. Вам нужно больше пропускной способности.
Да, и проголосовали за закрытие - serverfault.com
Вам действительно нужно выполнить профилирование на этом тренажере, чтобы разобраться с узкими местами. Я согласен с TomTom в том, что ваша доступная пропускная способность слишком мала, но вы также должны быть уверены, что у вас нет других проблем.
С помощью некоторого базового мониторинга производительности вы должны знать, какие проблемы вы наблюдаете на аппаратном уровне, но поскольку это приложение собственной разработки, уверены ли вы, что у вас там тоже нет проблем с кодированием? Не зная самого приложения, я могу только догадываться, оптимизировали ли вы свой код и доступ к базе данных, кэшируете ли вы там, где это необходимо, видите ли вы какую-то конкуренцию за ресурсы или блокировку базы данных, что явно является большей проблемой по мере увеличения количества пользователей и т. д. и т. д.?
Масштабируемость зависит как от приличной настройки оборудования, так и от хорошо написанного приложения, и оба аспекта необходимо рассматривать параллельно.
Как сказал TomTom, перед масштабированием вам необходимо определить текущее узкое место. Наиболее частыми узкими местами являются пропускная способность сети, оперативная память, производительность диска и ЦП. Вам нужно провести дополнительный мониторинг, чтобы выяснить, какие из них (или, возможно, что-то еще) вызывают вашу текущую проблему с производительностью.