Onderwerp: Spoed: Varnish-Setup

Oorspronkelijk geplaatst door Kevin Bentlage

Je zou die memory_limit tijdelijk steeds iets lager kunnen zetten, net zo laag totdat PHP tegen het limiet aanloopt. Wellicht kun je dan aan de error aflezen waar precies dit limiet bereikt wordt en of dit wel klopt.

Ik heb een pak van deze:

[core:error] [pid 317506:tid 140338442106624] [client xxx.xx.xx.xxx:25342] Script timed out before returning headers: index.php, referer: http://www.xxx.xxx/nl-BE

Ik zie het woord cache een aantal keer voorbij komen, maar nog niet in deze context: Wat als het plaatsen van een nieuw artikel nu de gehele/gedeeltelijke cache verwijderd? Bij nieuwe hits op de frontend wordt vervolgens alles weer opgebouwd. En dat kan aardig wat resources kosten. En dat ebt dan weer weg zodra de cache weer is opgebouwd. Bij veel cache oplossingen werkt het op deze manier.

Oorspronkelijk geplaatst door Arieh

Ik zie het woord cache een aantal keer voorbij komen, maar nog niet in deze context: Wat als het plaatsen van een nieuw artikel nu de gehele/gedeeltelijke cache verwijderd? Bij nieuwe hits op de frontend wordt vervolgens alles weer opgebouwd. En dat kan aardig wat resources kosten. En dat ebt dan weer weg zodra de cache weer is opgebouwd. Bij veel cache oplossingen werkt het op deze manier.

Die vraag stelde ik inderdaad ook deze ochtend aan de ontwikkelaar, maar nog geen antwoord. Maar dat zou toch geen 800 processen ipv 120-130 mogen zijn volgens mij

Wij hebben een site draaien, maar op Wordpress, en daar doet deze cache-oplossing dit ook, maar heeft amper invloed op de load

Oorspronkelijk geplaatst door Anoniem

Die vraag stelde ik inderdaad ook deze ochtend aan de ontwikkelaar, maar nog geen antwoord. Maar dat zou toch geen 800 processen ipv 120-130 mogen zijn volgens mij

Wij hebben een site draaien, maar op Wordpress, en daar doet deze cache-oplossing dit ook, maar heeft amper invloed op de load

Dit klinkt als een fuck-up in een PHP script waardoor je server een klap krijgt. Als het iets te maken had met gebruikers, hits of iets in die geest dan zou het na enkele minuten zichzelf oplossen en rustiger worden. Dat je echt handmatig actie moet ondernemen betekend dat er een loop ergens zit (of een andere php fout).

Oorspronkelijk geplaatst door CharlieRoot

Dit klinkt als een fuck-up in een PHP script waardoor je server een klap krijgt. Als het iets te maken had met gebruikers, hits of iets in die geest dan zou het na enkele minuten zichzelf oplossen en rustiger worden. Dat je echt handmatig actie moet ondernemen betekend dat er een loop ergens zit (of een andere php fout).

Lijkt me ook niet koosjer alvast:

Netwerkverkeer sinds opstart: 147,8 GiB

Deze MySQL-server draait inmiddels 0 dagen, 12 uren, 50 minuten en 22 seconden. Deze is gestart op 02 aug 2016 om 01:53.

Verkeer # ø per uur
Ontvangen 2,4 GiB 191,6 MiB
Verzonden 145,4 GiB 11,3 GiB
Totaal 147,8 GiB 11,5 GiB
Verbindingen # ø per uur %
Max. gelijktijdige verbindingen 340 --- ---
Mislukte pogingen 38 2,96 0,04%
Afgehaakte 5,084 395,97 5,60%
Totaal 91 k 7,065,96 100,00%

11.3Gb per uur uitgaand op de MYSQL

Kun je niet testen met alleen de backend? Dus dat de frontend tijdelijk niet toegankelijk is voor bezoekers en er vervolgens een artikel geplaatst wordt?

Het lijkt er meer gewoon op dat iets bij het plaatsen van het artikel voor een loop zorgt. Door dus de website tijdelijk volledig onbereikbaar te maken voor alles en iedereen zou je kunnen zien waar het aan ligt.

Je kunt bijvooorbeeld ook alleen toegang geven voor een IP-adres middels een de firewall of een htaccess bestand of iets dergelijks. Vervolgens post je een artikel en dan kijken wat er gebeurd op de server.

Een loop hoeft het nog niet eens te zijn. Er zijn gewoon logge sites die MySQL voor ieder wissewasje gaan raadplegen. Tientallen / honderden query's per hit. Een voorbeeld is Magento. Een site met een handjevol bezoekers kan je hele CPU volstoppen. Of een crawler die iedere pagina bij langs gaat. Of dat Bing en Google samen met ieder meerdere bots tegelijk bezig zijn.

Zonder de site verder te kennen is het moeilijk raden wat er hier nu aan de hand is, 99% zeker kunnen we denk ik wel zeggen dat het aan de website zelf ligt en dat dit niet met een magische server configuratie verholpen is.

Om verder te debuggen zou je ook kunnen overwegen om een kopie van de website apart online te zetten zodat het normale verkeer er geen last van heeft.

Mogen we inderdaad zeker van zijn.

Ook nog, van gisterenavond 23u tot nu, is de database van 931Mb, naar 1.33Gb gegaan ... De ontwikkelaar zoekt het verder uit, maar het Varnish-verhaal om dit op te lossen ligt uiteraard in de vuilnisbak ...

Na een deploy deze middag, zijn er wat verbeteringen, maar het blijft problematisch wanneer men in de backend aan het werk gaat. Dit heb ik zopas via New Relic opgevangen en valt perfect samen met het omhoog schieten van het aantal processen voor deze user:

http://users.telenet.be/bottie/screens/entity.jpg

Oorspronkelijk geplaatst door Anoniem

Na een deploy deze middag, zijn er wat verbeteringen, maar het blijft problematisch wanneer men in de backend aan het werk gaat. Dit heb ik zopas via New Relic opgevangen en valt perfect samen met het omhoog schieten van het aantal processen voor deze user:

http://users.telenet.be/bottie/screens/entity.jpg

Hmm drupal, die kan uit zichzelf al heel goed cachen ..

Er is een nieuwe deploy uitgevoerd en 'plots' draait alles als een zonnetje. Wanneer ik vraag wat de oplossing was:

Het enige wat we hebben gedaan is de caching afgestemd op de server. Qua code hebben we helemaal niets aangepast.

- Alle cachetabellen zitten in file cache, dus ipv in de databank worden deze nu op file niveau bijgehouden om de databank niet te belasten.
- Caching van advertenties is verder geoptimaliseerd (impressies worden via cron ipv page load geregistreerd)
- Megamenu is opgenomen in caching
- 404 pagina's worden opgevangen zodat ze geen resources verbruiken.
- ...

Maximale geheugenverbruik is nu amper 0,4-0,8Gb ipv 24Gb ...

Inderdaad zoals verwacht werd caching verkeerd benut en werd derhalve de MySQL server overbelast. Hoewel het misschien niet 'aan de code' lag, lag het wel aan de instellingen ervan. In ieder geval niet aan de server. Maar goed, met enige regelmaat zoekt de klant de oplossing bij de server in plaats van zijn eigen afdeling.