Попытка сделать то, что написано в заголовке: сохранить существующие сеансы под высокой нагрузкой и передать 503 сообщения вновь прибывшим посетителям.
Проблема: это работает, но сеансы не длятся более 90 секунд.
Текущие результаты заставляют меня задуматься, есть ли время ожидания, которое я пропускаю.
Цель
Я пытаюсь получить haproxy для:
- отправлять запросы на новые сеансы в серверную часть 001, когда общее число сеансов во внешнем интерфейсе ниже определенного порогового значения.
- обслуживать ошибку 503 для новых сеансов, когда общее число сеансов во внешнем интерфейсе превышает этот порог
- разрешить запросы на существующие сеансы, даже если количество сеансов превышает пороговое значение
Таким образом, посетители, которые находятся в процессе заполнения многоэтапной формы, не будут удивлены ошибкой 503, и новым посетителям можно будет сказать: «Пожалуйста, возвращайтесь позже, потому что мы действительно заняты сейчас».
Настроить
Установка выглядит следующим образом:
{visitors}
↓
[haproxy]
↓
[rails app on unicorn served by nginx] (right now just one
backend: 'backend-001')
текущий подход
Для достижения вышеизложенного я использую приведенную ниже конфигурацию.
Этот тест предназначен для тестирования с очень низким пределом (10 подключений на внешнем интерфейсе (fe_conn gt 10)), чтобы облегчить тестирование.
Чтобы поставить сервер под нагрузкой, я использую httperf следующим образом:
httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 - рейтинг 2
global
daemon
maxconn 10000
defaults
mode http
timeout connect 6s
timeout client 60s
timeout server 60s
balance roundrobin
option http-server-close
frontend http-in
bind [PUBLIC_IP]:80
default_backend backend-001
acl too_many fe_conn gt 10
use_backend b_too_many if too_many
backend backend-001
fullconn 10
appsession _session_id len 128 timeout 7200s
cookie SERVERID insert maxidle 7200s
server Server1 127.0.10.1:80 cookie backend-001 check
backend b_too_many
errorfile 503 /var/www/50x.html
проблема
Как уже упоминалось выше, проблема в том, что это почти работает, но сессии не длятся более 90 секунд.
Если вы продолжаете нажимать на кнопку, вы продолжите сеанс, даже если 10 сеансов заняты.
Попытка открыть страницу на сервере с другим экземпляром браузера приводит к ошибке 503.
Итак, похоже, я почти там. У кого-нибудь есть идея, что может быть причиной коротких сеансов?
И особенно как я могу это исправить :)
(отредактируйте: убрал 'weight 1 maxconn 10' из строки 'server', не имеет значения и может привести к путанице) (отредактируйте 2-е: исправлено '10 сессий на входе' в '10 соединений на входе')
Ответы:
К сожалению, вы, кажется, полностью путаете соединения с сеансами на уровне приложений. Пользователь, посещающий сайт, может иметь cookie, который заставляет вас думать, что он владеет соединением, хотя это не всегда так. Он может открыть столько соединений, сколько необходимо для извлечения объектов и навигации по страницам.
Несомненно, 90 секунд, которые вы наблюдаете, - это время ожидания активности браузера для незанятых соединений.
Можно достичь того, что вы хотите, но это немного сложнее, чем это, так как вы также должны учитывать наличие постоянных cookie в запросе, чтобы выяснить, является ли посетитель новым или нет.
Кроме того, в целом более эффективно полагаться на среднее число подключений к серверу, чем на число подключений внешнего интерфейса. Причина в том, что когда сервер умирает, вам нужно перенастроить это число. Наиболее эффективный способ сделать это - установить значение maxconn сервера, чтобы включить организацию очереди, и использовать avg_queue, чтобы ограничение применялось к среднему количеству запросов в очереди на серверах. Это позволяет правильно обрабатывать известных посетителей, одновременно мягко перемещая новых пользователей в другой бэкэнд, когда нагрузка увеличивается из-за существующих посетителей.
источник