HAproxy - langzaam met 1 bestand

[magentohosting]

Hoi allen,

Wellicht kunnen jullie iets zeggen over het volgende:
Op een dedicated server draaien meerdere webshops. Voor een deze webshops staat Varnish geconfigureerd. Varnish staat op een losse VPS zodat we op de dedi geen aanpassingen hoefde te doen m.b.t. Apache, poorten, etc. Varnish werkt momenteel goed, alleen ervaart de klant een probleem met HAproxy.

HAproxy wordt gebruikt om het https verkeer te loadbalancen tussen de dedicated server en dezelfde dedicated server. Deze config hebben we ook gebruikt bij een andere klant (in clusteropstelling) maar daar hebben we het volgende probleem niet:
Bij het openen van bijv. /mijn-account of wanneer je de checkout ingaat, ga je over naar een HTTPS verbinding. Wanneer je deze pagina voor het eerst opent, duurt het laden 15 tot 20 seconden. Het probleem zit hem hier in 1 of 2 css/js bestanden. Afhankelijk van de pagina worden beide ingeladen of 1 van de 2. Het laden van zo'n bestand duurt +- 10 seconden, wat echt erg lang is. Het bestand zelf is +- 550 KB. Wanneer ik dan rechtstreeks naar de dedicated server connect (zonder de loadbalancer/HAproxy/Varnish te gaan), dan is de pagina binnen paar seconden geladen.

Het lijkt dus ergens in HAproxy te zitten of in de connectie tussen de VPS en de dedicated server. Ik kan echter niet achterhalen wat het probleem is en ik twijfel of HAproxy zelf ook daadwerkelijk het probleem is; kom niet heel veel relevants tegen op internet namelijk en HAProxy wordt erg veel gebruikt. Kun jij is kijken of jij iets kunt vinden of heb je nog suggesties?

Iemand die ervaring heeft met HAproxy en een idee heeft waar dit kan zitten?

De gebruikte haproxy.cfg:

global
  log 127.0.0.1 local0
  maxconn 20000
  daemon
  uid 99
  gid 99
#  log /dev/log   local0 info
#  log /dev/log   local0 notice
defaults
  log     global
  timeout server 30s
  timeout connect 30s
  timeout client 30s

frontend https_frontend
  bind *:443
  mode tcp
  default_backend web_server

backend web_server
  mode tcp
  balance source
  stick-table type ip size 200k expire 90m
  stick on src
  server s1 *.*.*.48:443
  server s2 *.*.*.48:443

[xentos]

frontend https_frontend
bind *:443

Moet je daar geen SSL certificaat gebruiken? :
bind *:443 ssl crt /ssldir/sslkeyofcert.cert

voor de rest ziet het er goed uit. Kan niet zo 1.2.3 iets vinden dat verkeerd is.

[magentohosting]

Moet je daar geen SSL certificaat gebruiken? :
bind *:443 ssl crt /ssldir/sslkeyofcert.cert

Nee, dat gaat wel goed. Als ik de shop open krijg ik keurig het geïnstalleerde certificaat op de dedicated server.

[visser]

Hoi allen,

[..]
HAproxy wordt gebruikt om het https verkeer te loadbalancen tussen de dedicated server en dezelfde dedicated server. Deze config hebben we ook gebruikt bij een andere klant (in clusteropstelling) maar daar hebben we het volgende probleem niet:
Bij het openen van bijv. /mijn-account of wanneer je de checkout ingaat, ga je over naar een HTTPS verbinding. Wanneer je deze pagina voor het eerst opent, duurt het laden 15 tot 20 seconden. Het probleem zit hem hier in 1 of 2 css/js bestanden. Afhankelijk van de pagina worden beide ingeladen of 1 van de 2. Het laden van zo'n bestand duurt +- 10 seconden, wat echt erg lang is. Het bestand zelf is +- 550 KB. Wanneer ik dan rechtstreeks naar de dedicated server connect (zonder de loadbalancer/HAproxy/Varnish te gaan), dan is de pagina binnen paar seconden geladen.
[..]

Test eens met curl of wget als je direct die twee bestanden ophaalt (gewoon via loadbalancer/varnish/haproxy) of dat ook traag gaat.

En maak een capture met tcpdump van een hele sessie van een client, en ga kijken wat je ziet gebeuren rondom het moment dat die bestanden traag geladen worden.

[magentohosting]

Test eens met curl of wget als je direct die twee bestanden ophaalt (gewoon via loadbalancer/varnish/haproxy) of dat ook traag gaat.

En maak een capture met tcpdump van een hele sessie van een client, en ga kijken wat je ziet gebeuren rondom het moment dat die bestanden traag geladen worden.

Gaan we straks is proberen. Thanks!

[magentohosting]

Met wget zijn beide bestanden ook erg langzaam (37Kb p/s - duurt al met al een seconden of 10).

Voordat ik tcdump ga uitvoeren... heeft dat uberhaupt zin? Twijfel niet aan je expertise, maar het is een HTTPS verbinding. Dus daar zou je niet zoveel aan kunnen zien, toch?

[visser]

Met wget zijn beide bestanden ook erg langzaam (37Kb p/s - duurt al met al een seconden of 10).

Voordat ik tcdump ga uitvoeren... heeft dat uberhaupt zin? Twijfel niet aan je expertise, maar het is een HTTPS verbinding. Dus daar zou je niet zoveel aan kunnen zien, toch?

De inhoud van de transfer kun je niet zien, maar het verloop van TCP natuurlijk wel.
Ik denk niet dat de inhoud relevant is voor de trage throughput.
(Plus dat je in dit geval toch beheerder van de server bent ? Dan kun je in wireshark de ssl keyfile meegeven en de inhoud wel zien ).
Maar goed, de inhoud is niet relevant denk ik.

Omdat je het bij een wget/curl download ook ziet, kun je die download capturen, dan heb je niet de ruis van een hele webshop sessie erbij.
Wel wil je op of bij de client capturen.

Mijn eerste gedachte was dat er bij/rondom de download nog iets anders gedaan zou worden dan die bestanden downloaden.
Bijvoorbeeld een lookup/query voor een falende url. Zoals sommige websites traag laden als een ad url traag is, zeg maar.
Of iets in de processing/rendering van die css'en.

Door alleen het verdachte bestand met curl/wget te downloaden is die theorie wel uitgesloten.
Wat nog wel zou kunnen is de vertraging toch clientzijdig zit, omdat die het server certificaat gaat valideren door de revocation status op te vragen (zie 'ocsp' ).

Dat zijn dingen die je met tcpdump op/vlak voor de client kunt zien gebeuren.
Let dus wel op dat je niet eerst een filter op 'alleen verkeer met de loadbalancer op tcp/443' zet, want dan mis je nu juist een mogelijk trage ocsp transactie, de dns query/queries daarvoor, eventuele icmp pakketten die terugkomen etc.

Dus eventjes een capture van 'alles' van de client (en terwijl je test zet je even 'meuk' uit - refreshende mail clients, spotify players, 30 browser tabjes die reloaden etc ) , dan hoef je minder te filteren in je capture .

[magentohosting]

...

Thanks, ik ga er mee aan de slag!

[Mark17]

Tip: probeer het ook een keer te testen met wget/curl zonder haproxy/andere caching er bij tussen. Dan kun je bepalen of de caching mogelijk voor vertraging zorgt of dat het aan de webserver ligt.

[CharlieRoot]

Pak Firefox+firebug, het tabje 'net'. Zo kun je precies zien wát er zo lang duurt


----
Verzonden vanaf mijn mobiele telefoon

[magentohosting]

Pak Firefox+firebug, het tabje 'net'. Zo kun je precies zien wát er zo lang duurt

Dat is inmiddels al duidelijk. Het zijn elke keer dezelfde 2 bestanden die voor de vertraging zorgen. Afhankelijk van de pagina worden beide of slechts 1 bestand ingeladen. Beide bestanden zijn zo 600KB groot en hebben rond de 10 seconden nodig om volledig geladen te worden.

Mijn collega is er momenteel mee aan de slag. Hou jullie op de hoogte!

[magentohosting]

Kleine update:
Probleem lijkt opgelost te zijn. Bleek iets op de virtualisatielaag te zijn (exact weet ik het niet) waardoor er een buffer vol zou lopen.

Bedankt voor het meedenken allen!

[asusk7m550]

Hoe ben je daar achter gekomen? Misschien kunnen we daar iets van leren.

[magentohosting]

Hoe ben je daar achter gekomen? Misschien kunnen we daar iets van leren.

Om eerlijk te zijn: ik heb geen idee! :-). Collega heeft dat nader bekeken en van wat ik begreep kwam hij daar met enige toeval achter.

[visser]

Om eerlijk te zijn: ik heb geen idee! :-). Collega heeft dat nader bekeken en van wat ik begreep kwam hij daar met enige toeval achter.

Ik ben toch wel benieuwd. Kun je nog wat navragen/toelichten ?
Met name waarom nu die twee files langzaam waren, en de rest blijkbaar niet ?

Stonden toevallig die files op een ander backend dan 'de rest' , of liepen die als enige over ssl ?
Kortom, naast de vraag 'waarom traag' ook 'waarom juist/alleen die files traag ' .