Попытка сделать то, что написано в заголовке: сохранить существующие сеансы под высокой нагрузкой и передать 503-сообщение вновь прибывшим посетителям.
Проблема: это работает, но сеансы длятся не более 90 секунд.
Текущие результаты заставили меня задуматься, есть ли параметр тайм-аута, который мне не хватает.
Я пытаюсь настроить haproxy на:
Таким образом, посетители, которые находятся в процессе заполнения многоступенчатой формы, не будут удивлены ошибкой 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 --rate 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.
Итак, похоже, я почти у цели. Кто-нибудь знает, что может быть причиной короткого времени сеанса?
И особенно как я могу это исправить :)
(отредактируйте: убрано «вес 1 maxconn 10» из строки «server», не имеет отношения к делу и может сбивать с толку) (отредактируйте 2-е: исправлено «10 сеансов на интерфейсе» на «10 подключений на интерфейсе»)
К сожалению, вы, кажется, полностью запутали соединения с сеансами на уровне приложений. Пользователь, посещающий сайт, может иметь файл cookie, который заставляет вас думать, что он владеет соединением, хотя это не всегда так. Он может открывать столько соединений, сколько необходимо для извлечения объектов и навигации по страницам.
90 секунд, которые вы наверняка наблюдаете, - это таймаут активности браузера для незанятых соединений.
Возможно достичь того, чего вы хотите, но это немного сложнее, поскольку вам также необходимо учитывать наличие файла cookie сохранения в запросе, чтобы выяснить, является ли посетитель новым или нет.
Также, как правило, более эффективно полагаться на среднее количество подключений на сервер, чем на количество подключений внешнего интерфейса. Причина в том, что когда сервер умирает, вам нужно перенастроить это число. Наиболее эффективный способ сделать это - установить значение maxconn сервера, чтобы включить создание очередей, и использовать avg_queue, чтобы ограничение применялось к среднему количеству запросов в очереди на серверах. Это позволяет правильно обрабатывать известных посетителей, плавно перемещая новых пользователей на другой сервер, когда нагрузка увеличивается из-за существующих посетителей.