Вопрос: haproxy: сохранить существующие сеансы под высокой нагрузкой, подать «503» новым участникам


Попытка сделать то, что он говорит в названии: сохранить существующие сеансы под высокой нагрузкой и передать сообщение 503 новоприбывшим посетителям.

Проблема: он работает, но сеансы длится не более 90 секунд.

Текущие результаты заставляют меня задаться вопросом, нет ли тайм-аута, который у меня отсутствует.

Цель

Я пытаюсь получить haproxy:

  • отправлять запросы на новый сессий для backend-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 - сервер 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» из «серверной линии», не имеет значения и может запутать) (отредактируйте 2-й: скорректированные «10 сеансов на интерфейсе» на «10 соединений на интерфейсе»)


12
2017-08-22 10:35


Источник


Может быть, глупый вопрос - что такое keep_alive в nginx? По-видимому, это по умолчанию 75 штук - может ли это быть проблемой? - Aidan Kane


Ответы:


К сожалению, вы, кажется, совершенно запутываете связи с сеансами на уровне приложений. Пользователь, посетивший сайт, может иметь cookie, который заставляет вас думать, что он владеет соединением, в то время как это не обязательно так. Он может открыть столько соединений, сколько необходимо для извлечения объектов и навигации по страницам.

90 секунд, которые вы наблюдаете, - это тайм-аут браузера для простоя подключений.

Можно добиться того, чего вы хотите, но это немного сложнее, чем это, так как вы также должны учитывать наличие cookie-файла настойчивости в запросе, чтобы выяснить, является ли посетитель новым или нет.

Кроме того, в общем случае более эффективно полагаться на среднее количество подключений на сервер, чем на количество подключений к интерфейсу. Причина в том, что когда сервер умирает, вам нужно перенастроить это число. Самый эффективный способ сделать это - настроить значение maxconn сервера для включения очередности и использовать avg_queue, чтобы предел применялся к среднему числу запросов на очереди на серверах. Это позволяет корректно обрабатывать известных посетителей, мягко перемещая новых пользователей на другой бэкэнд, когда загрузка увеличивается из-за существующих посетителей.


4
2017-08-25 08:05



Спасибо Спасибо! Это прояснилось. Теперь у меня есть работа (среди прочего) проверка бэкэнда-файла cookie с помощью hdr_sub (Итак, «hdr_sub (cookie) SERVERID = backend-001»). После завершения работы я опубликую рабочую конфигурацию. - Apenootje