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

haproxy: сохранять существующие сеансы при высокой нагрузке, показывать '503' новым прибывшим

Попытка сделать то, что написано в заголовке: сохранить существующие сеансы под высокой нагрузкой и передать 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, чтобы ограничение применялось к среднему количеству запросов в очереди на серверах. Это позволяет правильно обрабатывать известных посетителей, плавно перемещая новых пользователей на другой сервер, когда нагрузка увеличивается из-за существующих посетителей.