Профессионалы и недостатки репликации сессии
Если Ваши результаты даже около общего приблизительного значения для Вашего сценария (по крайней мере, тысячи запросов в секунду на маленькие статические файлы, по крайней мере, сотни запросов в секунду на простой динамический PHP, возможно, меньше для тяжелого динамического контента с базами данных и материалом) должен иметь, и сервер все еще двигается с пыхтением вперед приятно, то Вы в порядке.
Также важно, чтобы во время сервера нагрузочного теста все еще имел пространство для дыхания. Если это едва имеет в запасе какое-либо процессорное время или дополнительную память, то Вы собираетесь быть в большой проблеме во время внезапных транспортных скачков и/или роста Вашего сайта.
Доверяйте своим инстинктам. Если у Вас есть просто маленькая база данных для содержания, и во время сравнительного теста сервер базы данных, кажется, ест много ЦП, пойдите и перепроверьте все. Сервер базы данных сам настроен хорошо? Существуют все ожидаемые индексы? Сайт выполняет некоторые half-assed SQL-запросы, которые могли оптимизироваться и/или кэшироваться? Что-то еще? Или если Ваш веб-сервер, кажется, проводит много времени, даже раздающего статическое содержание, проверьте настройки веб-сервера.
И если Вы, окажется, будете сравнивать абсолютно медленного поскольку патока сайта, то Вы будете знать, что существует комната для оптимизации. Я когда-то сравнил на вид простого сайта, работающего с сервером с 8 ядрами, 16 ГБ RAM и всего того джаза. ab, осада и JMeter все дали мне пять запросов в секунду! В той точке я знал, что что-то было очень, очень плохо неправильно. Достаточно иронически это было полностью неправильно сконфигурировано плагин кэша, получающий доступ memcached, который был неправильным. После фиксации, что сайт был приблизительно в 100 раз быстрее.:-)
Мне кажется, что вы, администраторы, пытаетесь создать отказоустойчивую среду, чтобы при отключении одного сервера пользователи не испытали никаких заметных изменений. Это также может быть сделано по причинам обслуживания, чтобы они могли работать на одном из серверов, не влияя на другие.
В этом сценарии приложение и веб-сервер должны будут предоставить своего рода абстрактную репликацию сеанса или кэш для хранения информации о сеансе. в случае, если исходный отвечающий сервер отключается.
По сути, это предотвращает выгрузку ваших пользователей из приложения и необходимость повторного входа в систему.
Как упоминает Джон выше, это действительно сводится к бизнес-требованиям, если высокая доступность нужен, у вас действительно нет выбора в этом вопросе. Так или иначе,
Этот вопрос восходит к моему бизнес-аргументу - каковы SLA приложений? Если в соглашении об уровне обслуживания указано, что вы можете потратить от 5 до 10 секунд на завершение переключения на вторичный сервер после того, как первичный будет активирован и принудительно перезапустит сеанс на клиенте, что резко упростит репликацию. Если в вашем соглашении об уровне обслуживания указано, что у вас есть 0,5 секунды на восстановление после сбоя и / или вам не разрешено принудительно перезапустить сеанс, тогда позвольте SA запустить репликацию и использовать ее.
«Нам нужна балансировка нагрузки и кластеризация» предполагает мне кажется, что ваши SLA таковы, что вам также нужна репликация сеанса, но это я только читаю.