haproxy: сохранить существующие сессии под высокой нагрузкой, обслуживать «503» для вновь прибывших

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