PHP

PHP workers

PHP workers verwerken de PHP code van een site. Denk hierbij aan het bouwen van pagina’s, het verwerken van achtergrondtaken, het bevragen van de database, enz.

Je kunt PHP workers vergelijken met werknemers in een winkel. Elke worker kan maar één verzoek tegelijk verwerken. Als er meer klanten zijn dan werknemers, moeten die klanten (processen) in de rij gaan staan en wachten op de volgende beschikbare werknemer om hun verzoek af te handelen.

PHP workers komen pas echt van pas als een site de meeste inhoud niet in de cache heeft of kan opslaan. Hoe dynamischer een website is, hoe meer PHP workers deze waarschijnlijk nodig heeft. Gecachete content heeft geen PHP workers nodig; ze zijn eigenlijk alleen nodig als de site de database moet raadplegen om informatie op te vragen of te wijzigen.

Als het gaat om de prestaties van WordPress, betekenen meer PHP workers niet automatisch betere prestaties; er zijn een aantal factoren waar je rekening mee moet houden:

• Caching: Effectieve caching kan de werkdruk op PHP workers verminderen door inhoud vanuit de cache te leveren in plaats van deze dynamisch te genereren voor elk verzoek. Dit kan de prestaties aanzienlijk verbeteren, vooral voor veelgebruikte bronnen.
• Hardware: De beschikbare hardware-resources op de server, zoals CPU, geheugen (RAM) en schijfsnelheid, hebben een directe invloed op de prestaties van PHP workers. Onvoldoende bronnen kunnen leiden tot langzamere verwerkingstijden en slechtere prestaties.
• Webserverconfiguratie: De configuratie van de webserver en zijn interactie met PHP kan de prestaties van de worker beïnvloeden.
• Databasesnelheid: PHP applicaties halen vaak gegevens op uit MySQL databases om dynamische inhoud te renderen. De snelheid waarmee gegevens worden opgehaald wordt beïnvloed door zaken als hoe de database is georganiseerd, hoe queries zijn geoptimaliseerd en hoe goed de database server presteert. Dit heeft direct invloed op hoe goed PHP applicaties draaien.
• PHP versie: Nieuwere PHP versies zorgen vaak voor betere prestaties van PHP workers door prestatieverbeteringen, bugfixes en beveiligingsupdates.

Bij Kinsta hechten we veel waarde aan de prestaties van je site. Daarom hebben we verschillende technologieën geïmplementeerd die gericht zijn op het maximaliseren van PHP prestaties en het minimaliseren van PHP verzoeken:

• We bieden paginacaching op zowel CDN- als serverniveau, met aanpasbare regels om maximale cache-efficiëntie te garanderen.
• We gebruiken premium servers bij GCP (C2 en C3D virtuele machines) die zijn uitgerust met de snelste CPU’s van Google Cloud om de PHP-workers van je site efficiënter te laten werken.
• Onze schaalbare infrastructuur zorgt ervoor dat de PHP-workers van je WordPress site genoeg CPU-resources hebben om optimaal te presteren.
• We maken gebruik van een eersteklas netwerkinfrastructuur bij Google Cloud Platform (GCP) om latency te minimaliseren. Door gebruik te maken van het hoogwaardige netwerk van GCP verkorten we de tijd die gegevens nodig hebben om te reizen tussen de verschillende onderdelen van onze infrastructuur, waaronder de MySQL server en webservers, aanzienlijk.
• We bieden een sterk geoptimaliseerde MySQL server die lokaal wordt gehost om de netwerklatency te verminderen en het ophalen en verwerken van gegevens te versnellen.
• Op de MySQL server hebben we InnoDB buffers om de databaseprestaties te helpen verbeteren door schijf I/O operaties te verminderen. Gegevens kunnen sneller worden benaderd vanuit het geheugen in plaats van vanaf schijf, waardoor lees- en schrijfbewerkingen efficiënter verlopen en de algehele prestaties van de MySQL database verbeteren.
• We zorgen ervoor dat altijd de nieuwste versie van PHP beschikbaar is om eventuele prestatieverbeteringen te integreren.

PHP workers vs. PHP geheugenlimiet

Het aantal PHP workers moet niet worden verward met de PHP geheugenlimiet. PHP workers zijn individuele PHP processen die inkomende webverzoeken afhandelen, terwijl de PHP geheugenlimiet de maximale hoeveelheid geheugen (RAM) specificeert die een enkel PHP script kan gebruiken tijdens de uitvoering.

PHP workers beheren gelijktijdigheid (concurrency) door meerdere verzoeken tegelijk te verwerken, terwijl de PHP geheugenlimiet de toewijzing van resources beheert door het geheugengebruik van afzonderlijke scripts te beperken. Dit voorkomt dat één script al het beschikbare geheugen van de server gebruikt.

PHP geheugenlimieten zijn belangrijk voor scripts die veel geheugen nodig hebben, zoals scripts die grote databasequeries uitvoeren, grote bestandsuploads verwerken of complexe berekeningen uitvoeren. Als je geheugenlimietfouten tegenkomt op je site, zal het verhogen van het aantal PHP workers dit probleem niet oplossen. In plaats daarvan moet je je geheugenlimiet controleren en, indien nodig, verhogen of een geheugenlimiet add-on kopen.

WordPress en PHP workers

Een ongecachet verzoek op een WordPress site gaat meestal ongeveer zo:

1. Een bezoeker bezoekt een pagina of voert een actie uit op een pagina (bijvoorbeeld iets toevoegen aan een winkelwagentje, een formulier versturen, enz.)
2. De webserver (Nginx hier bij Kinsta) ontvangt dat verzoek.
3. Nginx geeft het verzoek door aan PHP.
4. PHP bevraagt de MySQL database en krijgt de informatie die het nodig heeft of voert de benodigde updates uit.
5. PHP gebruikt dan de PHP-bestanden van je thema (en eventuele plugin-bestanden) om een HTML-pagina te genereren.
6. PHP geeft de gerenderde HTML-pagina terug aan de webserver.
7. De pagina wordt geleverd aan de bezoeker.

In het hierboven beschreven proces kost stap 4 de meeste tijd en middelen (CPU en RAM). Een goed geoptimaliseerde site met efficiënte PHP-code en databasequeries zal deze stap vrij snel verwerken.

Slecht geschreven of niet-geoptimaliseerde PHP-code en/of veel inefficiënte database queries zullen er daarentegen veel langer over doen om stap 4 te doorlopen. Verzoeken die langer duren om te verwerken monopoliseren PHP workers voor langere tijd.

Het aantal benodigde PHP workers schatten

Hoeveel workers een site nodig heeft hangt af van verschillende factoren, zoals: hoe dynamisch de site is, hoe geoptimaliseerd de code van de site is (hoe snel verzoeken kunnen worden verwerkt) en wat voor soort verkeer de site ontvangt. Een geoptimaliseerde site verwerkt verzoeken snel, waardoor PHP workers vrij zijn voor het volgende verzoek in de wachtrij.

Dynamische sites zoals e-commerce winkels, forums, leersites en lidmaatschapssites hebben meestal meer PHP workers nodig dan meer statische, brochure-achtige sites. En hoe drukker een site is, hoe meer PHP workers deze meestal nodig heeft.

Kinsta pakketten en PHP workers

De volgende tabel laat zien hoeveel PHP workers zijn inbegrepen bij elk pakket van Kinsta:

We bieden ook pakketten op maat waarbij je zelf kunt aangeven hoeveel PHP workers je nodig hebt. Neem voor meer informatie contact op met ons verkoopteam.

PHP workers, CPU en RAM

Bij het toevoegen van PHP workers moet je rekening houden met CPU en RAM resources. Als je het aantal PHP workers verhoogt, maar de server heeft meer CPU en RAM nodig om die workers te ondersteunen, dan zal dit een knelpunt veroorzaken omdat de verzoeken niet efficiënt zullen worden afgehandeld.

Hier bij Kinsta zijn onze custom LXD containers geconfigureerd met voldoende CPU en RAM resources. Daarnaast helpen we de PHP workers van je site efficiënter te werken door gebruik te maken van C2 en C3D virtuele machines die zijn uitgerust met de snelste CPU’s van Google Cloud. Onze schaalbare infrastructuur zorgt ervoor dat de PHP workers van je WordPress site genoeg CPU-bronnen hebben om topprestaties te leveren.

Prestatieproblemen met betrekking tot PHP workers identificeren

Als te veel verzoeken zich opstapelen in de wachtrij door een grote toestroom van verzoeken, langlopende processen of een combinatie van beide, kan de site prestatieproblemen ondervinden die kunnen resulteren in 502 of 504 fouten.

Het gebruik van tools zoals Kinsta’s APM tool en de Query Monitor plugin kunnen je helpen bij het identificeren van prestatieproblemen en trage queries. We raden ook aan om samen te werken met een gekwalificeerde prestatie-expert om problemen te diagnosticeren.

Limieten PHP workers

Je kunt de PHP worker limiet grafiek bekijken in MyKinsta > WordPress Sites > sitenaam > Analytics > Prestaties > PHP worker limiet. Als een PHP worker gedurende 10 aaneengesloten seconden niets te doen heeft, wordt het PHP worker proces automatisch beëindigd. Zodra het weer nodig is, wordt het worker proces direct opnieuw aangemaakt. Deze grafiek laat zien hoe vaak het maximum aantal toegewezen workers op je site is bereikt.

Als je bijvoorbeeld een Business 1 pakket afneemt, dan staat dit maximaal 4 PHP worker processen toe. Als er 3 PHP workers in gebruik zijn en er wordt een ander verzoek gedaan op je site waarvoor een PHP worker nodig is, dan wordt bij het aanmaken van de PHP worker het maximum aantal van 4 PHP workers bereikt en gelogd als een incident waarbij de limiet voor PHP workers is bereikt.

Dit geeft je mogelijk slechts een gedeeltelijk beeld van je PHP worker activiteit, omdat dit alleen het aantal keren registreert dat de limiet van de PHP worker is bereikt en niet hoe lang alle PHP workers in gebruik waren.

Als je site bijvoorbeeld een enorme verkeersdrukte ervaart, kunnen alle PHP workers een heel uur lang constant bezig blijven zonder inactieve tijd en daarom helemaal niet worden beëindigd tijdens dat uur. Dit zou slechts worden geregistreerd als één geval waarin de limiet van de PHP workers is bereikt, en daarom kan het lijken alsof de PHP workers niet bezet waren gedurende dat uur, terwijl ze in feite allemaal de hele tijd actief waren. Na 30 minuten, als er een afname in verkeer is waardoor een PHP worker 10 seconden niet actief is, zal deze automatisch worden beëindigd. Als de PHP worker echter binnen een minuut weer nodig is, wordt het maximum aantal PHP workers weer bereikt, waardoor er weer een PHP worker limiet wordt vastgelegd.

Als je de websiteprestaties onderzoekt en vaststelt of je site continu zijn PHP workers gebruikt, kun je de activiteit van PHP workers controleren met tools in een SSH sessie. Het volgende custom commando controleert bijvoorbeeld elke 0,3 seconden het aantal actieve PHP workers:

watch -n 0.3 "ps aux | awk '$(NF-2) ~ /php-fpm/ && $(NF-1) ~ /pool/ && $8 ~ /R/ { print $0 }' | wc -l"

Om dit commando af te sluiten, druk je op CMD + C of CTRL + C en laat je beide toetsen los.

Cache analytics

De cache analytics sectie in MyKinsta cache analytics kan worden gebruikt om het totaal aantal cacheverzoeken en de top cacheomleidingen van je site te bekijken.

Verbruik PHP workers verminderen en optimaliseren

Caching

Caching is je beste vriend als het gaat om het optimaliseren van je site en het verminderen van het aantal benodigde PHP workers. Onthoud dat PHP workers niet nodig zijn voor content die je levert vanuit de cache, dus cache alles wat je kunt.

Pagina caching

Bij Kinsta verzorgen we pagina caching voor je; alle sites gebruiken de FastCGI cache module van Nginx voor supersnelle prestaties.

Object cache

Het toevoegen van een persistent object cache zoals Redis voor je database kan de prestaties verbeteren en de behoefte aan PHP workers verminderen. Zonder object caching worden MySQL databasequeries uitgevoerd voor elk verzoek, zelfs als het dezelfde query en resultaten zijn.

Redis slaat de resultaten van databasequeries op in RAM zodat PHP die resultaten kan ophalen zonder de query opnieuw uit te voeren. Het verwijderen van de noodzaak voor herhalende databasequeries zorgt ervoor dat PHP workers resources kunnen besparen en verzoeken efficiënter kunnen uitvoeren.

Bekijk onze premium add-ons voor meer informatie over het toevoegen van Redis cache aan je site.

Code-optimalisatie

Zorg ervoor dat de code van je site zo efficiënt mogelijk is. Dit geldt voor aangepaste code, themacode en plugincode. Als je het niet zeker weet, raden we je aan een ontwikkelaar te vragen om de code van je site te bekijken.

Custom code

Als je website je eigen code snippets bevat in plugins of je thema, zorg er dan voor dat ze echt nodig zijn en goed geschreven.

Plugins

Kijk goed naar de plugins die op de site worden gebruikt en controleer of ze echt nodig zijn, geen dubbele functies bevatten en de beste optie zijn voor de behoefte die ze vervullen. Als er plugins zijn die niet compatibel zijn met de nieuwste versie van WordPress en PHP, is het misschien tijd om andere opties te overwegen. Als je plugins op je site hebt die niet worden gebruikt, is het aan te raden om die te verwijderen.

Thema

Gebruik een lichtgewicht en goed presterend thema. Vermijd thema’s die functionaliteit bevatten die het beste via aparte plugins kan worden geïmplementeerd (zoals SEO, zoekfiltering, aangepaste velden, sliders/slideshows voor afbeeldingen, etc.) of die niet nodig zijn voor je site.

PHP bijwerken

Gebruik de nieuwste PHP-versie voor snellere prestaties. PHP benchmarks laten zien dat elke PHP versie sneller is dan de vorige.

Kinsta’s CDN inschakelen

Het inschakelen van Kinsta’s CDN zorgt voor nog meer efficiëntie en optimalisatie voor je site. Kinsta CDN is onze high-performance HTTP/3 CDN, ondersteund door Cloudflare, die je zonder extra kosten ter beschikking wordt gesteld. Als het is ingeschakeld, kan je site statische assets van locaties over de hele wereld serveren.

Raadpleeg een prestatie-expert

Als je bekend bent met siteoptimalisatie, is dit een optionele stap. Een expert kan je helpen om alle aspecten van je site te analyseren, knelpunten te identificeren en oplossingen te implementeren.

PHP herstarten

Als PHP uitvalt, logt ons systeem dit automatisch zodat ons Systems Administration (sysadmin) team dit kan controleren. Je kunt PHP echter handmatig opnieuw opstarten voor elk van je websites afzonderlijk met een simpele klik op een knop vanuit MyKinsta.

PHP handmatig herstarten

Volg de onderstaande stappen om PHP opnieuw op te starten op je WordPress site.

1. Log in op MyKinsta.
2. Ga naar WordPress sites en selecteer de site waarop je PHP opnieuw wilt opstarten.
3. Ga naar het tabblad Tools en zoek naar de sectie PHP opnieuw opstarten.
4. Klik op de knop Herstart PHP.

Houd er rekening mee dat het opnieuw opstarten van PHP ongeveer 5-10 seconden duurt. Je krijgt een melding onderaan het scherm wanneer het is voltooid.

Opmerking: Je moet ook de cache van je site verwijderen om de wijzigingen te kunnen zien.

PHP limieten

Als Managed WordPress service heeft Kinsta de optimale PHP instellingen geconfigureerd om het beste te werken met WordPress sites. Als je specifieke PHP vereisten hebt, voel je dan vrij om contact op te nemen met ons Support Team om je behoeften te bespreken.

Kinsta biedt PHP 8.1, 8.2 en 8.3. Dit zijn de standaardinstellingen voor PHP:

• memory_limit = 256M
• post_max_size = 128M
• upload_max_filesize = 128M
• max_input_vars = 10000
• max_execution_time = 300

Je kunt deze waarden eventueel verhogen. Neem contact op met ons Support Team om uit te vinden welke opties voor jou beschikbaar zijn.

PHP geheugenlimiet

Kinsta’s standaard PHP geheugenlimiet is 256MB, wat meer dan genoeg is voor de meeste WordPress plugins en sites. Deze limiet bestaat om te voorkomen dat PHP scripts te veel geheugen verbruiken. Als je de limiet te hoog instelt, kan een verkeerd geconfigureerd of kapot script ernstige problemen veroorzaken door te veel geheugen te gebruiken.

Als je site correct is ingesteld bij Kinsta, zou je niet tegen een geheugenlimietfout aan moeten lopen. Als je deze fout ziet, raden we je aan je WordPress instellingen te controleren om er zeker van te zijn dat deze niet per ongeluk te laag zijn ingesteld.

Als je de PHP geheugenlimiet van een site wilt verhogen, kun je een PHP geheugenlimiet add-on kopen. Deze add-on verhoogt de geheugenlimiet van 256 MB naar 512 MB voor een bedrag van $50 per site per maand.

Om deze add-on aan te schaffen ga je in MyKinsta naar WordPress sites > sitenaam > Add-ons en klik onder PHP geheugen op Wijzigen.

Er wordt een nieuw venster geopend met de prijsinformatie; klik op Open chat om een chat te starten met ons Account Management team, dat de add-on voor je zal instellen.

Je kunt ook contact opnemen met het Account Management team via de live chat in MyKinsta Dashboard of door ons te e-mailen op [email protected].

Als je de PHP geheugenlimiet add-on verwijdert en je zit in de eerste 30 dagen van je WordPress Hosting pakket, dan wordt een evenredig bedrag voor de add-on toegevoegd aan je volgende factuur voor de periode dat deze was ingeschakeld. Als je WordPress Hosting pakket langer dan 30 dagen actief is, ontvang je een evenredig tegoed voor de add-on kosten op je Accountsaldo voor de resterende dagen van de huidige factureringsperiode. Het tegoed wordt automatisch gebruikt om het aan Kinsta verschuldigde geld op je volgende factuur te verrekenen. Raadpleeg voor meer informatie onze WordPress Hosting niet-goed-geld-terug-garantie.

Je PHP geheugenlimiet controleren en wijzigen

Om je huidige PHP geheugenlimiet voor WordPress te controleren, log je in op het WordPress dashboard van je site en navigeer je naar Tools > Site Health.

Ga naar het tabblad Info en klik op het pijlpictogram naast het Server gedeelte om dit gedeelte uit te vouwen en je PHP geheugenlimiet te bekijken.

Als de geheugenlimiet lager is dan 256M, controleer dan je wp-config.php bestand om te zien of de WP_MEMORY_LIMIT is aangepast en pas het zo nodig aan.

Als de geheugenlimiet 256M is, maar je hebt problemen met PHP geheugen, dan raden we aan om plugins en thema’s te controleren en te testen. Je kunt een testomgeving gebruiken om plugins en thema’s veilig te deactiveren en opnieuw te activeren om de bron van het geheugengebruik te identificeren.

Als de fout blijft bestaan en je de bron niet kunt identificeren, kun je een nieuwe chat openen met ons Support Team om de logs te controleren en problemen aan de serverzijde uit te sluiten.

PHP bijwerken

We hebben het bijwerken van de PHP versie van je site zo eenvoudig mogelijk gemaakt in MyKinsta.

In MyKinsta kun je de PHP versie voor één of meerdere sites, inclusief testsites, tegelijkertijd bijwerken vanaf de WordPress sites pagina. Selecteer de selectievakjes naast de site(s) waarvoor je de PHP versie wilt bijwerken, klik op Acties en kies PHP versie wijzigen.

Selecteer de versie waarnaar je wilt updaten en klik op PHP versie wijzigen.

Zodra het proces is voltooid, verschijnt er een succesbericht.

Je kunt ook de PHP versie voor een enkele site bijwerken binnen WordPress sites > sitenaam > Tools. Klik onder PHP engine op het uitklapmenu en selecteer de PHP versie waarnaar je je site wilt bijwerken.

Klik in het modal/popupvenster PHP versie wijzigen dat verschijnt op de knop PHP versie wijzigen om de wijziging te bevestigen.

Aan het einde van de update wordt je PHP engine opnieuw opgestart en kan de back-end (WordPress dashboard) van je site een paar seconden down zijn. De front-end van de site blijft in de lucht en bezoekers zullen geen downtime ervaren.

Terwijl het updateproces loopt, kun je navigeren naar andere delen van MyKinsta, maar sommige acties, zoals cachebeheer, zullen niet beschikbaar zijn totdat de PHP-engine opnieuw is opgestart.

Zodra de update is voltooid (meestal binnen 3 minuten of minder), ontvang je een melding in MyKinsta dat het is voltooid.

PHP constants

PHP constants slaan vaste waarden op die overal op je site hetzelfde blijven. Ze zijn automatisch globaal, wat ideaal is voor waarden die op meerdere plaatsen toegankelijk moeten zijn.

Als je een niet-standaard WordPress setup gebruikt, zoals Bedrock of Trellis, kan Kinsta mogelijk de variabele DB_PASSWORD niet vinden en kan daarom het databasepaswoord niet bijwerken wanneer je:

• Een nieuwe site toevoegt door een bestaande omgeving te klonen
• Een testomgeving toevoegt door een bestaande omgeving te klonen
• Een testomgeving naar live zet
• Een backup terugzet
• Het database wachtwoord wijzigt in MyKinsta

Om dit probleem op te lossen, biedt Kinsta de SERVER_SECRET_DB_PASSWORD PHP constant voor gebruik op de Kinsta servers. Wanneer je deze constante definieert in het bestand config.php, gebruikt MyKinsta deze om het databasewachtwoord van je site te identificeren. Je kunt het als volgt definiëren:

define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );

Je kunt de volgende PHP constants definiëren voor gebruik met Kinsta servers:

• SERVER_SECRET_DB_USER
• SERVER_SECRET_DB_PASSWORD
• SERVER_SECRET_DB_HOST
• SERVER_SECRET_DB_NAME

Je kunt de constants bijvoorbeeld als volgt definiëren in het bestand config.php:

define('DB_NAME', defined('SERVER_SECRET_DB_NAME') ? SERVER_SECRET_DB_NAME : 'newsitetest');
define('DB_USER', defined('SERVER_SECRET_DB_USER') ? SERVER_SECRET_DB_USER : 'newsitetest');
define('DB_PASSWORD', defined('SERVER_SECRET_DB_PASSWORD') ? SERVER_SECRET_DB : 'asdijfhkjasdbfkjhbajiksd' );
define('DB_HOST', defined('SERVER_SECRET_DB_HOST') ? SERVER_SECRET_DB_HOST : 'localhost');

Je kunt de constants ook als volgt definiëren:

define('DB_NAME',SERVER_SECRET_DB_NAME);
define('DB_USER',SERVER_SECRET_DB_USER);
define('DB_PASSWORD',SERVER_SECRET_DB_PASSWORD);
define('DB_HOST',SERVER_SECRET_DB_HOST);

PHP modules

De volgende PHP modules zijn standaard geïnstalleerd op je WordPress site op Kinsta:

• bcmath
• bz2
• calendar
• Core
• ctype
• curl
• date
• dom
• exif
• FFI
• fileinfo
• filter
• ftp
• gd
• gettext
• hash
• iconv
• igbinary
• imagick
• imap
• intl
• json
• libxml
• mbstring
• mysqli
• mysqlnd
• openssl
• pcntl
• pcre
• PDO
• pdo_mysql
• Phar
• posix
• readline
• redis
• Reflection
• session
• shmop
• SimpleXML
• soap
• sockets
• sodium
• SPL
• standard
• sysvmsg
• sysvsem
• sysvshm
• tokenizer
• xml
• xmlreader
• xmlwriter
• xsl
• Zend OPcache
• zip zlib

ionCube is niet standaard geïnstalleerd, maar kan worden ingeschakeld als je site PHP 8.1, 8.2 of 8.3 draait binnen MyKinsta > WordPress sites > sitenaam > Tools > ionCube Loader > Inschakelen.

Als je vragen hebt over een specifieke PHP-module die niet in de bovenstaande lijst staat, neem dan contact op met het supportteam van Kinsta.