haproxy: zachowaj istniejące sesje pod dużym obciążeniem, serwuj „503” nowo przybyłym

Próbując zrobić to, co napisano w tytule: zachowaj istniejące sesje pod dużym obciążeniem i przekaż 503 wiadomości nowo przybyłym użytkownikom.

Problem: działa, ale sesje nie trwają dłużej niż około 90 sekund.

Obecne wyniki sprawiają, że zastanawiam się, czy brakuje mi limitu czasu.

Cel, powód

Próbuję uzyskać haproxy do:

• wysyłać żądania nowych sesji do zaplecza-001, gdy łączna liczba sesji w interfejsie jest poniżej określonego progu.
• podawać błąd 503 do nowych sesji, gdy łączna liczba sesji w interfejsie przekracza ten próg
• zezwalaj na żądania dotyczące istniejących sesji, nawet jeśli liczba sesji przekroczy próg

W ten sposób odwiedzający, którzy są w trakcie wypełniania wieloetapowego formularza, nie będą zaskoczeni błędem 503, a nowi odwiedzający mogą otrzymać polecenie „wróć później, ponieważ jesteśmy teraz bardzo zajęci”.

Ustawiać

Konfiguracja jest następująca:

            {visitors}
                ↓ 
            [haproxy]
                ↓ 
[rails app on unicorn served by nginx]   (right now just one 
                                            backend: 'backend-001')

obecne podejście

Aby osiągnąć powyższe, używam poniższej konfiguracji.

Ten jest przeznaczony do testowania, z bardzo niskim limitem (10 połączeń na froncie (fe_conn gt 10)), aby ułatwić testowanie.

Aby obciążyć serwer, używam httperf w następujący sposób:

httperf --hog --server staging.machine.tld --uri / do_some_things --wsess = 500,10,30 - stopa 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

problem

Jak wspomniano powyżej, problem polega na tym, że: prawie działa, ale sesje nie trwają dłużej niż około 90 sekund.

Jeśli będziesz klikać, możesz kontynuować sesję, nawet jeśli jest 10 zajętych sesji.

Próba otwarcia strony na serwerze z inną instancją przeglądarki powoduje błąd 503.

Wygląda na to, że już prawie jestem. Czy ktoś ma pojęcie, co może powodować krótkie czasy sesji?

A szczególnie jak to naprawić :)

(edytuj: usunięto „weight 1 maxconn 10” z linii „server”, nie dotyczy i może się mylić) (edytuj drugą: poprawioną „10 sesji w interfejsie” do „10 połączeń w interfejsie”)

Niestety wydaje się, że całkowicie mylisz połączenia z sesjami na poziomie aplikacji. Użytkownik odwiedzający stronę może mieć plik cookie, który sprawia, że ​​myślisz, że jest właścicielem połączenia, choć niekoniecznie tak jest. Może otworzyć tyle połączeń, ile potrzeba, aby pobrać obiekty i poruszać się po stronach.

90 sekund, które obserwujesz, to z pewnością czas oczekiwania przeglądarki na bezczynne połączenia.

Możliwe jest osiągnięcie tego, co chcesz, ale jest to nieco bardziej skomplikowane, ponieważ musisz również wziąć pod uwagę obecność cookie trwałego w żądaniu, aby dowiedzieć się, czy użytkownik jest nowy, czy nie.

Również ogólnie bardziej efektywne jest poleganie na średniej liczbie połączeń na serwer niż na liczbie połączeń interfejsu użytkownika. Powodem jest to, że kiedy serwer umiera, musisz ponownie ustawić ten numer. Najskuteczniejszym sposobem na to jest skonfigurowanie wartości maxconn serwera, aby umożliwić kolejkowanie, oraz użycie avg_queue, aby limit dotyczył średniej liczby żądań w kolejce na serwerach. Pozwala to poprawnie obsługiwać znanych użytkowników, a jednocześnie przenosić nowych użytkowników do innego zaplecza, gdy obciążenie wzrasta z powodu istniejących użytkowników.