Onderwerp: Spoed: Varnish-Setup

Goede Middag,

Bestaand systeem:

6-Core Xeon met 32Gb RAM en 4x 2Tb HDD in RAID10
Cloudlinux + PHP-Selector

1 klant vraagt een Varnish-setup voor zijn site, alle andere sites moeten blijven werken zoals ze werken. Ik zoek dus iemand die dit 'meteen' kan zien te klaren.

Probleem is, klant zijn site draait perfect (+- 50.000 unieke bezoekers/dag) maar van het moment iemand in de backend gaat en een nieuw artikel schrijf, gaat alles qua processen en geheugengebruik de lucht in (van +/- 130 processen naar +800). Ontwikkelaar site beweert dat dit op te lossen valt met Varnish ... Of een hosting bij hen zelf, uiteraard)

Ik heb zelf geen ervaring met Varnish en wil dit dus ook niet uitproberen op een live omgeving, maar het lijkt mij erg stug dat Varnish dit probleem gaat oplossen. Het schrijven van een nieuw artikel en publishen lijkt mij niet 670 extra processen te kosten. Varnish doet meer voor de frontend.

Varnish is inderdaad een frontend cache, en moet geconfigureerd worden met een VCL. Behalve als de klant een bekend CMS gebruikt (Magento, etc.) is dat flink wat handwerk om die te maken. Je zal dan alle dynamische blokken met de hand moeten holepunchen. Dingen zoals backends zijn typisch niet goed te cachen en het schrijven van nieuwe artikelen / toevoegen producten al helemaal niet.

Het probleem zal je dus met Varnish niet kunnen oplossen. Ik zou even New Relic of Blackfire.io installeren en kijken waar de bottleneck zit.

PHP-Selector heb je al geprobeerd om overbodige functies uit te schakelen, en OPCACHE aan te zetten om te kijken of dit helpt ?
en misschien MySQL optimaliseren want heb je van mysql geen hoge load tijdens het uitvoeren in de backend ?

Het zou natuurlijk kunnen dat bij het posten van het nieuwe artikel bijvoorbeeld een link op diverse socialmedia kanalen wordt geplaatst en dat er in 1x een berg bezoekers op de site komen.

Dit zou de verhoging van het aantal processen wel kunnen verklaren, zeker als er WordPress gebruikt wordt die standaard niets cached.

In dat geval kan Varnish zeker wel uitkomst bieden, de pagina wordt dan nog maar 1x gegenereerd door WordPress en vervolgens volledig uit de cache geserveerd. Dit ontlast de backend enorm.

Echter is het aardig wat werk om de VCL goed af te stemmen, daarnaast is het afhankelijk van de bouw en structuur van de website of het wel of geen zin heeft. Zo worden pagina's waarop cookies / sessies aanwezig zijn standaard niet gecached. Ook pagina's met dynamische content (welke verschilt per gebruiker, bijvoorbeeld laatst bekeken artikelen) kan niet gecached worden.

Ik zou eventueel morgen wel kunnen kijken (helaas niet direct). Het inrichten van een beetje standaard VCL kost tussen de 2 en 4 uur werk voor een relatief simpele site, als de site complex is dan kan dit snel oplopen omdat alle onderdelen afzonderlijk bekeken (en indien caching wel of niet mogelijk is, geconfigureerd) moeten worden.

De opmerking dat dit niet opgelost zal worden met de Varnish-setup, heb ik ook gemeld aan de ontwikkelaar van de site (diezelfde partij biedt zelf ook hosting aan ), maar na het aanpassen van een aantal parameters en dergelijke op hun advies blijft het gewoon hetzelfde probleem.

Door de dag zit er bijna geen belasting in de gemiddelde load, aantal mysql-connecties of draaiende processen. Posten ze een artikel, dan draait het in de soep. Op 1 minuut van 130 tasks en 6Gb geheugengebruik naar +500 en 20Gb is niet koosjer. En er is geen auto-publish op social media actief. Het probleem is dus louter op de manier van posten/bewaren van het artikel.

Ik heb een New Relic draaien, maar de PHP Agent heeft daar een probleem mee ... Idem voor Blackfire vrees ik

De installatie van Varnish is dus even 'minder dringend' maar op termijn wel nodig, het traceren van de oorzaak des te dringender

Oorspronkelijk geplaatst door Anoniem

Ik heb een New Relic draaien, maar de PHP Agent heeft daar een probleem mee ... Idem voor Blackfire vrees ik

Met Cloudlinux bedoelde ik dus

Oorspronkelijk geplaatst door Anoniem

De opmerking dat dit niet opgelost zal worden met de Varnish-setup, heb ik ook gemeld aan de ontwikkelaar van de site (diezelfde partij biedt zelf ook hosting aan ), maar na het aanpassen van een aantal parameters en dergelijke op hun advies blijft het gewoon hetzelfde probleem.

Door de dag zit er bijna geen belasting in de gemiddelde load, aantal mysql-connecties of draaiende processen. Posten ze een artikel, dan draait het in de soep. Op 1 minuut van 130 tasks en 6Gb geheugengebruik naar +500 en 20Gb is niet koosjer. En er is geen auto-publish op social media actief. Het probleem is dus louter op de manier van posten/bewaren van het artikel.

Ik heb een New Relic draaien, maar de PHP Agent heeft daar een probleem mee ... Idem voor Blackfire vrees ik

De installatie van Varnish is dus even 'minder dringend' maar op termijn wel nodig, het traceren van de oorzaak des te dringender

Wat voor processen worden er gestart? Zijn dit de processen van webserver/database/etc..

Oorspronkelijk geplaatst door Peter Bin

Wat voor processen worden er gestart? Zijn dit de processen van webserver/database/etc..

Een massa /usr/local/php55/bin/php-cgi55 commands, aangeroepen door de index.php

En hoe lang houd deze drukte dan aan na het posten? Is het een enkele hoge piek of blijft het daarna nog enige tijd "druk" op de server?

Oorspronkelijk geplaatst door Kevin Bentlage

En hoe lang houd deze drukte dan aan na het posten? Is het een enkele hoge piek of blijft het daarna nog enige tijd "druk" op de server?

Ik moet de user 'suspenden', anders komt er geen eind aan. 'iets' gaat dus in een loop.

Als ik via Cloudlinux betreffende user 8Gb geheugen toewijs, vult die 8Gb op. Geef ik 16Gb, dan vult die gewoon 16Gb op ... Als ik dan de user terug op actief zet, werkt alles perfect totdat iemand terug via de Drupal backend een nieuw artikel post, dan gaat alles terug in de soep

Is er wellicht iets in de error logs te vinden?

Oorspronkelijk geplaatst door Anoniem

Ik moet de user 'suspenden', anders komt er geen eind aan. 'iets' gaat dus in een loop.

Als ik via Cloudlinux betreffende user 8Gb geheugen toewijs, vult die 8Gb op. Geef ik 16Gb, dan vult die gewoon 16Gb op ... Als ik dan de user terug op actief zet, werkt alles perfect totdat iemand terug via de Drupal backend een nieuw artikel post, dan gaat alles terug in de soep

Zijn er bepaalde plugins geladen die "iets doen" bij het posten van een artikel? Wellicht kun je die 1 voor 1 uitschakelen om te kijken of de problemen daar wellicht uit voort komen.

Hoe hoog staat het memory_limit van PHP?

Oorspronkelijk geplaatst door Kevin Bentlage

Zijn er bepaalde plugins geladen die "iets doen" bij het posten van een artikel? Wellicht kun je die 1 voor 1 uitschakelen om te kijken of de problemen daar wellicht uit voort komen.

Hoe hoog staat het memory_limit van PHP?

Memory_limit staat op 512mb

Site-Ontwikkelaar claimt dat er niks mis is met de site, maar biedt, uiteraard, aan mijn klant een wel werkende omgeving aan

Alle andere, ook drukbezochte, sites op de server werken overigens wel perfect

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.