Hoge CPU-belasting van WordPress - processor, server en hosting. Sterke toename van de CPU-belasting op hosting

Tijdens de exploitatie van de site is een periode van ongeveer 30 dagen verstreken meer problemen geen en hoge belasting van de server, de processor wordt niet meer in acht genomen. Nu moet ik je vertellen hoe ik met periodieke high omging WordPress laden per processor en server.

Het begon allemaal volkomen spontaan en elke dag werd de reactie van de server steeds langer. Vervolgens op een bepaald punt in het paneel webmaster Yandex, verscheen een overeenkomstige kritische melding. Waarin een lange reactie van de server werd aangegeven op bijna 40 - 50 pagina's van de site. Alles is in orde.

Inhoud van het artikel:

Hoge belasting gecreëerd door een WordPress-site op de CPU van de server - de belangrijkste symptomen van dit probleem

Op mijn site ontstond het probleem volledig spontaan en op verschillende tijdstippen. De 100% belasting van de CPU van de server werd veroorzaakt door overgangen tussen sitepagina's. Rond de tweede pagina was er een scherpe sprong in de prestaties van de serverprocessor. Ik zou willen opmerken dat het RAM op dit moment vrijwel geen fluctuaties kent. En het aantal processen is volkomen onbeduidend en zou niet zo'n schadelijke belasting moeten zijn serverprocessor.

Basis karakteristieke kenmerken ladingen waar veel webmasters mee te maken krijgen:

• Het verhogen van de CPU-belastingslimiet op de hostingserver.
• WordPress is gestart een onaanvaardbare belasting van de CPU veroorzaken.
• Piekwaarden, ernstige CPU-overbelasting op hosting.
• Lange serverreactie, variabele waarde varieert van 5 tot 30 seconden.
• Overmatige belasting treedt spontaan op, op verschillende tijdstippen.
• De site vertraagt, pagina’s laden nauwelijks of dit proces duurt erg lang.
• De site crasht op piekniveaus.
• WP zorgt voor een lange serverreactie, de site is niet stabiel. Tijdens piek CPU-pieken werkt het RAM in de normale stabiele modus.
• Het aantal getroffen en uitgevoerde processen tijdens piekperiodes is minimaal.
• Streaming batchtoegang en verbindingen op nginx of apache zijn minimaal.
• Deze anomalie treedt meerdere keren per dag op, met verschillende tussenpozen. Het eindigt net zo snel als het begon.

Dit is precies wat er een maand lang met mijn site is gebeurd. Een duidelijk voorbeeld er zullen de volgende afbeeldingen zijn:

Zoals u kunt zien, is het aantal betrokken processen minimaal. RAM wordt op een stabiele waarde gehouden, rekening houdend met browser openen En enorme hoeveelheid pagina's. Maar alle CPU-kernen werken onder kritieke belasting, en in eerste instantie is het onmogelijk om de reden helemaal te begrijpen.

Welke methoden heb ik geprobeerd om de kritieke belasting van de CPU te bestrijden?

Het meest voorkomende is dat ik me schuldig maakte aan WP-plug-ins en een gebrek aan geheugen. Hoewel de engine, eerlijk gezegd, slechts 16 MB geheugen gebruikt van de toegestane 512 MB die ik heb toegewezen. Wat ik eigenlijk heb geprobeerd:

• Heeft een volledige Debian-update uitgevoerd en vervolgens het hele systeem opgeschoond.
• 99% van de opgeslagen databaserevisies op VestaCp verwijderd.
• Ik heb er twintig keer naar gekeken configuratiebestanden in VestaCp op fouten.
• Gevonden binnen mailserver Exim groot aantal systeemlogboeken (volledig verwijderd).
• Ik heb de site gecontroleerd op virussen (die zijn er niet).
• Ik heb een trace naar de site uitgevoerd en de snelheid van de internetverbinding gecontroleerd.
• Op de site heb ik het opslaan van recordrevisies uitgeschakeld; ik heb verder niets op de site gedaan. De site is geoptimaliseerd voor 98% van de reden om deze te controleren.

Na alle ondernomen stappen is het probleem nog steeds niet opgelost. Gedurende de maand bleven de pieken en kritische piekbelastingen van WP op de serverprocessor doorgaan.

Wat was precies het probleem van overmatige WP-belasting op de CPU en hoe ik dit heb opgelost

Het probleem was een WP Cron-fout. Ongeveer vier maanden geleden heb ik een plug-in geïnstalleerd die voorkomt dat de engine, thema's en plug-ins worden bijgewerkt. De eerste oproep, zoals ik het begrijp, waren fouten in de serverlogboeken van de site, geadresseerd aan wp-cron.php. De fout zat in de toewijzing van geheugen voor het proces, of beter gezegd in onvoldoende geheugen. Toen ik me deze situatie herinnerde, merkte ik het meteen op.

Wat mij heeft geholpen:

• Ik heb de plug-in geïnstalleerd WP Controle— wp cron-taakplanner. Ik raad je aan om het meteen te installeren, een hele goede oplossing.
• Na de installatie zag ik de afbeelding erin piekbelasting uit ongeveer 900 identieke gebeurtenissen die, zoals ik het begrijp, betrekking hebben op beelden.

De eenvoudigste oplossing is om alle wp cron-gebeurtenissen naar hun oorspronkelijke staat te resetten, dit wordt gedaan in functies.php. Voeg het gewoon helemaal aan het begin van het bestand eronder in

Als gevolg hiervan verdwenen alle 900 evenementen en begon de site soepel te werken. Er zijn geen ernstige belastingen meer op de server en lange responstijden. Het enige waar ik vanaf moest, was het verbod op updaten. Daarna waren alle problemen opgelost. Zo zien de belastingsindicatoren er momenteel uit:

Ik hoop dat dit artikel nuttig is en je helpt. Als je vragen hebt, schrijf dan in de reacties of PM.

Nu zal ik je vertellen hoe ik er eindelijk in slaagde de CPU-belasting van mijn gehoste WordPress-sites te verminderen. Dit verhaal duurde 3 maanden. De CPU-indicator in mijn account had al de limiet bereikt en begon plotseling volledig buiten de schaal te vallen.

Ik weet niet precies hoeveel artikelen ik op internet heb gelezen en hoeveel forums ik heb gesurft. Wat ik gedurende deze tijd op mijn sites heb gedaan.

• Het aantal plug-ins geminimaliseerd. Je moet vooral letten op zware plugins met complexe scripts. U kunt dergelijke veelvraat detecteren met behulp van de P3-plug-in (Plugin Performance Profiler)
• Het gewicht van de foto's is verminderd. Het is ook raadzaam om de hoeveelheid te verminderen, maar zonder screenshots zal het moeilijk zijn om te begrijpen waar we het over hebben
• Een caching-plug-in geïnstalleerd - Hyper Cache
• De belasting veroorzaakt door zoekbots verminderd

Maar het hielp mijn sites niet als graankorrels voor een olifant. De verdomde CPU liet al meer dan 40-50 eenheden zien, hoewel mijn tarief er 30 toestond. Mijn host, webhost1, stoorde me niet. Maar ik raakte in paniek, vooral omdat op een mooie dag mijn sites automatisch werden uitgeschakeld - ook al duurde dit enkele minuten. En ik moest overstappen naar een duurder tarief.

En de CPU op de hosting begon op sommige dagen off-scale te gaan, zelfs boven de 50. Moet ik overstappen naar een andere hosting? De ophef is ongelooflijk, vooral omdat ik al meer dan 3 jaar op de webhost zit. En waar is de garantie dat de geschiedenis zich niet zal herhalen of nog erger zal worden? Het enige dat overbleef was het sluiten van de locaties of het betalen van een onrealistische (niet-terugvorderbare) prijs. Maar ik wilde dit niet doen, dus ging ik ronddwalen in mijn hostingpaneel.

En zie, de methode van wetenschappelijk porren hielp zoals altijd! Ik ging naar de domeinen en vergeleek de PHP van oude en nieuwe sites. Het bleek dat de oude sites op een verouderde versie van PHP5.3 werkten, en de nieuwe op PHP5.6!!! Ik heb mijn “oudjes” overgezet naar PHP5.6 en slaap nu al voor de derde maand vredig. CPU-belasting op hosting is gestabiliseerd.

Als je CPU het door het dak laat gaan en je hebt het antwoord nog steeds niet gevonden, controleer dan op welke versie van PHP je site draait. Op mijn hosting moet je hiervoor naar het hostingpaneel in de sectie Domeinen gaan. Klik vervolgens op Instellingen

Zoek in Instellingen naar PHP en selecteer versie 5.6 door op de driehoek te klikken. En bespaar. Hierna zou de CPU-belasting moeten afnemen. Kies gewoon niet versie 7.0, anders kunnen uw afbeeldingen en sitethema verdwijnen.

• Vergeet niet uw database elke week op te schonen. Plug-ins: en .
• Download nieuwe bijgewerkte versies van plug-ins en de WordPress-engine. Vooral als je updates niet hebt uitgeschakeld - dit wordt overigens niet aanbevolen, hoewel er op internet artikelen zijn met advies over het uitschakelen van updates. Naar verluidt vermindert deze methode de belasting aanzienlijk - vermindert deze, maar met niet meer dan 3-5 eenheden! Maar u stelt uw websites bloot aan het gevaar gehackt te worden, omdat kwetsbaarheden in elke nieuwe versie van de engine of plug-ins worden gedicht. Bezoek daarom uw sites minstens één keer per week en accepteer updates.

Ik ben blij als ik je kan helpen en je niet langer wordt geconfronteerd met de vraag hoe je de belasting van de hosting-CPU kunt verminderen.

Hoe vraatzuchtig WordPress wordt met de release van elke bijgewerkte versie, waardoor steeds meer hostingbronnen nodig zijn waarop onze blog zich bevindt, velen weten dit al. Er zijn geen hopeloze situaties, alles moet op rolletjes lopen en op zulke momenten

Extra tools genaamd plug-ins komen ons te hulp - werkpaarden, assistenten bij het werk van onze blogs. Wat zouden we zonder hen doen? Om het laden van de blog te verbeteren en te versnellen, zullen we eenvoudige plug-ins installeren om het laden van de blog te optimaliseren en te versnellen. In het artikel van vandaag zullen we een plug-in installeren voor het opschonen van het bloggebied WP-Optimize. Hoe plug-ins te installeren,

WordPress-optimalisatieplug-ins
1 - WP-optimalisatie helpt bij het optimaliseren van de database en sitetabellen. Dit is een plug-in die je moet hebben.
WP - Optimaliseer functies:

• Concreet reinigt het onze hulpbronnen van alle soorten afval.
• Optimaliseert - comprimeert de blogdatabase en tabellen.
• Verwijdert alle back-upkopieën van vermeldingen wanneer we een artikel op een blog plaatsen en hetzelfde bericht meerdere keren bewerken, evenals alle gepubliceerde inhoud.
• Verwijdert spam-opmerkingen.
• Conflicteert niet met andere plug-ins.
• Eenvoudige en standaard installatie op uw blog.
• Log in op het beheerderspaneel
• Plug-ins
• Nieuw toevoegen
• Voer in de zoekbalk de naam WP-Optimize in
• Installeren
• Activeren

Dan is het nog eenvoudiger: zoek in het menu aan de linkerkant op de naam WP-Optimize, ga naar instellingen, bekijk foto's van mensen die je hebben bedankt met een like.
Klik op Vind ik leuk en stuur het naar Facebook. Als je geen like stuurt, is de plug-in stil en zal deze niet werken. Net zoals stommen en doven niets kunnen horen, blijft deze plug-in inactief. Dit is mijn verhaal

gebeurde tijdens de installatie totdat ik eraan dacht een like te sturen. Totdat u de plug-inontwikkelaars bedankt, zal de plug-in niet werken. Wet van het Universum: om iets te ontvangen, moet je eerst zelf iets geven. Nog een axioma: verwacht niet het tegenovergestelde als je niet goed doet. Bekijk vervolgens deze schermafbeelding

Let op wat rood gemarkeerd is, kijk hiernaast naar het aantal kilobytes, ga helemaal naar beneden - hier is de totale hoeveelheid afval in Kb.
Voordat je de blog opschoont, ga je naar de reacties, het is waarschijnlijk dat een paar of drie goede reacties in spam terecht zijn gekomen: het komt voor dat opa

Akismet overdreef het - hij is ook een betrouwbare bewaker van de blog tegen spammers en heeft voor de veiligheid verschillende reacties in de spammap geplaatst. Hij verdient zijn brood. :)
Nu kun je het schoonmaken. We plaatsen op alle punten selectievakjes en drukken op het woord PROCES.

We hebben het schoongemaakt, we zijn blij met de algemene netheid. Alles wat rood gemarkeerd was, werd blauw. U wordt geïnformeerd: Totale vrije ruimte over: 33.105 Kb. Niet te veel, niet te weinig, het gebied is schoon. Blogoptimalisatie was succesvol.

Na het opschonen deactiveert u de plug-in en maakt u het bloggedeelte eens in de 5-7 dagen schoon.
2. De volgende plug-in is een klassieke plug-in die niet hoeft te worden geconfigureerd - standaard kent hij zijn functies van A tot Z. De auteur van de plug-in, Makarov, heeft hiervoor zijn best gedaan en ik vond de plug-in op de website sidash.ru/ van Dmitry Sidash, waar ik vaak rondkijk op zoek naar interessante en nuttige informatie. Kom binnen en je zult zelf veel leren.

SSD Optimaliseer WordPress- Ik onderscheid dit werkinstrument van de enorme hoeveelheid plug-ins die nuttig, niet erg nuttig, niet erg nuttig zijn, maar een goede belasting voor de server en de blog creëren. Het verlost de hosting van overmatig verkeer en vroegtijdige verzoeken, optimaliseert het laden van AJAX-bibliotheken onderweg, schakelt onnodige functies uit die het systeem zwaar belasten en interfereert tegelijkertijd niet met de prestaties van onze blog.

Welke voordelen halen we uit deze plug-in:

• Schakelt het controleren op updates voor thema's, plug-ins en engine uit
• Schakelt het automatisch opslaan van het bewerkte item uit
• Inclusief automatische optimalisatie en databaseherstel
• Schakelt postrevisies uit
• Schakelt het genereren van metatags uit
• Laadt AJAX-bibliotheken van de Google-website voor gebruikers
• Het verminderen van de belasting op de server dankzij de plug-in
• Zeven functies beschermen uw site tegen spam
• Verbod op actieve links in reacties

Installeert op dezelfde manier als alle plug-ins.

Het domein is niet verdwenen, de site bestaat nog steeds, maar deze plug-in ontbreekt. Links naar verschillende onderwerpen... Wanneer u op de link van de auteur klikt, verschijnt het volgende item:

Fout 404 Helaas staat hier niet wat u zoekt. Dit kan vele redenen hebben, maar u hoeft niet boos te zijn, aangezien u de populairste artikelen op mijn blog kunt lezen of vanaf de hoofdpagina kunt zoeken naar de informatie die u nodig heeft.

Er verscheen een website op internet, ik weet niet eens wanneer, maar om de een of andere reden staat hij nu in de AGS. De link zal hier inactief zijn: http://makarou.com/ssd-optimize-wordpress-5-0. Hoe u deze plug-in kunt downloaden: Selecteer de link http://makarou.com/ssd-optimize-wordpress-5-0, kopieer en plak in de adresbalk. Maar de bovenstaande link is actief, downloaden en installeren.

Instellingen voor onze SSD Optimize WP-tool

Informatie over plug-ins

Alle functies uitgevoerd

Statistieken over reacties en trackbacks

Mijn Skype-gvozdika571
Altijd blij om je op mijn blog te zien

Hoe kan ik de belasting van een WordPress-site op het gebied van hosting verminderen en de database optimaliseren?

Ik begon deze vraag te stellen nadat de Timeweb-hostingondersteuningsdienst mij schreef dat mijn websites (er zijn er 10 op deze hosting) de centrale hostingprocessen en de database te zwaar belasten. De toegenomen belasting was deels te wijten aan een DDoS-aanval op een van mijn sites, en daarnaast aan het feit dat ik al heel lang (meer dan 1,5 jaar) sites op deze hosting host, en er geen werk is gedaan aan het opschonen het opruimen van afval uit of het optimaliseren van databases heeft niet plaatsgevonden. Maar een website is tot op zekere hoogte te vergelijken met een computer. Als u onnodige bestanden, scheuren en andere onzin niet verwijdert, zal de computer na verloop van tijd opeten en meer bronnen nodig hebben, wat zal leiden tot vertragingen in de werking en frequente bevriezingen. Daarom moet u uw sites met zorg behandelen en regelmatig stappen ondernemen om de prestaties ervan te optimaliseren.

Hoe kan ik de WordPress-hostingbelasting verminderen en de database (MySQL) optimaliseren?

Ik heb kleine acties uitgevoerd (die ik later zal bespreken), waardoor ik de belasting van de hosting-CPU aanzienlijk kon verminderen. Over het algemeen zijn we erin geslaagd de belasting van de CPU te verminderen van 30-40 naar 0,34 - 0,50, en de belasting van de database te verminderen van 90 naar 64-70.

Als gevolg van de acties die zijn ondernomen om de database (MySQL) te optimaliseren, is de omvang ervan teruggebracht van 227 MB naar 41 MB. Zoals we kunnen zien, zijn we erin geslaagd significante resultaten te bereiken. Wat werd hiervoor gedaan?

Het blijkt dat alle acties die in WordPress worden uitgevoerd (of het nu gaat om het publiceren van een nieuw artikel, of simpelweg het toevoegen van een nieuwe plug-in, enz.) enig effect hebben op de database, waardoor deze in omvang toeneemt. En hoe groter de omvang ervan, hoe meer verschillende bestanden het bevat, die zich in een ongeorganiseerde volgorde bevinden, hoe groter de belasting van de hostingprocessen. Door te werken aan het optimaliseren van de database kunt u deze belasting dus aanzienlijk verminderen.

Om de database te optimaliseren, moet u de plug-in installeren en activeren - Optimize DB (lees hoe u plug-ins installeert). Ga vervolgens naar het gedeelte "Extra" - zoek de regel "DB optimaliseren" en volg deze. Om de database op uw website te optimaliseren, hoeft u nu alleen maar op de knop “Nu optimaliseren” te klikken.

Deze eenvoudige acties optimaliseren uw WordPress-database (om zo te zeggen, organiseer de chaos erin en zet alles in de schappen). Om te voorkomen dat de werking van deze plug-in in de toekomst voor extra belasting zorgt, hoeft u deze alleen maar uit te schakelen. Om uw WordPress-database één keer per week of één keer per maand te optimaliseren, gaat u naar het gedeelte Plug-ins, activeert u de plug-in Optimize DB en optimaliseert u MySQL (dit is de database). En schakel het vervolgens weer uit.

Maar om de belasting van de hosting te verminderen, heb ik mezelf niet beperkt tot alleen het werken met de Optimize DB-plug-in. Er is veel werk verricht om spam te bestrijden. Op verschillende sites heeft zich een bijzonder grote hoeveelheid spam verzameld (in totaal meer dan 6.000 stuks). Over spam gesproken, ik bedoel reacties van spam-achtige aard, waarvan een groot aantal ook de hosting belast. Ik heb veel reacties verwijderd in afwachting van verificatie (meer precies, om ze volledig te verwijderen - ik heb ze in eerste instantie naar de prullenbak gestuurd en vervolgens de prullenbak geleegd) en ook de spammap gewist. Onlangs heeft de plug-in “Invisible Captcha” mij veel geholpen. Dankzij dit wordt spam onmiddellijk naar de spammap gestuurd en van daaruit kunnen alle spamreacties onmiddellijk worden verwijderd door deze map te legen.

Ik zou je ook aanraden om de plug-in “WP Super Cache” te installeren (als deze nog niet is geïnstalleerd), deze te activeren en caching in te schakelen. Dit is vooral handig als veel bezoekers uw sites al bezoeken. Ondertussen heb ik het op nog een paar sites geïnstalleerd. Dankzij caching wordt ook de belasting van de hosting verminderd.

Zo werd er op 10 werven gewerkt, wat mij ongeveer 2 uur kostte. Maar ik heb mijn doel bereikt: ik ben erin geslaagd de belasting van WordPress-hosting aanzienlijk te verminderen.

Het is ook vermeldenswaard dat hoe meer verschillende er op een WordPress-site worden geactiveerd, hoe groter de belasting. Gebruik daarom alleen de plug-ins die u nodig heeft en schakel de plug-ins uit die u niet gebruikt.

Laten we waarschijnlijk beginnen met optimaliseren. Laten we gaan!

Een voorbeeld van overmatige belasting van de server.

Stel dat een gebruiker de site bezoekt, maar wat gebeurt er als de pagina wordt geopend? Hoe wordt informatie op het scherm weergegeven? Laten we dit proces volgen met de sitekop als voorbeeld.

De titel en URL van de hoofdpagina van de site zijn, als u het zich herinnert, ingesteld in de WordPress-instellingen: admin -> Opties -> Algemeen. Alle instellingen die beschikbaar zijn op het tabblad “Opties” worden ingevoerd in de database, of beter gezegd, in de wp-options-tabel, van waaruit ze vervolgens door verschillende functies worden opgevraagd en op het scherm worden weergegeven.

WordPres-ontwikkelaars hebben nogal wat functies geschreven, maar deze kunnen niet op zichzelf worden uitgevoerd. Voor hun volwaardige werk is een bepaalde verbindende link vereist, waarvan de rol de sitesjabloon is.

Een sjabloon bestaat, zoals u weet, uit een aantal bestanden, die elk verantwoordelijk zijn voor het weergeven van een specifiek gedeelte van de site. We zijn nu geïnteresseerd in de koptekst, waar de titel wordt weergegeven, dus laten we openen bestand header.php en laten we kijken wat daar geschreven staat.

In de meeste sjablonen is de hoofdtitel van de site ingesloten in de h1-tag, dus we zijn op zoek naar een codegedeelte met deze tag. In mijn sjabloon zag de header-uitvoercode er als volgt uit:

/">

Geweldig, de titel moet een link zijn, dus de code bevat de constructie anker . Maar wat is dit geschreven in plaats van een link? En het anker is een beetje vreemd. Maar dit is een duidelijk voorbeeld van overmatige belasting van de server.

We zullen het anker iets later behandelen, maar laten we nu eerst kennis maken met de functie get_option().

get_option() functie en serverbelasting

We hebben dus de naam en URL van de hoofdpagina van de site ingevoerd in de WordPress-instellingen en deze werden opgeslagen in de database, in de wp-options-tabel.

Op het moment dat de gebruiker een pagina van onze bron opent en het header.php-bestand de header begint te laden, wordt de functie get_option() geactiveerd.

Het werkingsprincipe van de bovengenoemde functie is om toegang te krijgen tot de database, of beter gezegd de wp-options-tabel, en daaruit bepaalde gegevens te verkrijgen, op basis van de gespecificeerde parameters. Daarna het elftal echo geeft de ontvangen gegevens weer op het scherm.

Het is een beetje ingewikkeld, maar dat is oké, ik zal nu alles uitleggen. Tussen haakjes wordt een parameter aangegeven, in ons geval get_option('home') , die de functie vertelt welk type gegevens deze moet ontvangen.

De home-parameter instrueert de functie om de homepagina-URL op te vragen uit de database. Stop! Dus de URL van de startpagina wordt ook in de database opgeslagen? Rechts. En wanneer de pagina wordt geopend, vraagt ​​de functie erom, dat wil zeggen dat deze toegang krijgt tot de gegevens die op de server zijn opgeslagen.

Stel je nu voor dat 100 bezoekers naar je bron kwamen en begonnen te spelen, waarbij ze steeds meer pagina's openden.

U heeft waarschijnlijk wel eens gehoord van hackeraanvallen op verschillende sites, waarbij duizenden of zelfs miljoenen verzoeken tegelijkertijd de server bereiken, waardoor de server uitvalt en de bron wordt geblokkeerd.

We moeten begrijpen dat als we het aantal verzoeken aan de database verminderen, we de server vrijer zullen laten ‘ademen’ en dat hij de vrijgekomen bronnen voor nuttigere dingen zal gebruiken, wat uiteraard de laadsnelheid van de pagina zal beïnvloeden.

Laten we terugkeren naar de functie get_option(). Om bepaalde gegevens uit de database te verkrijgen, kan de functie de volgende parameters accepteren:

get_option("home") - URL van de startpagina
get_option("admin_email") — E-mailadres van de sitebeheerder;
get_option("blognaam") — Sitenaam;
get_option("blogdescription") - Korte beschrijving van de site;
get_option("blog_charset") — Sitecodering;
get_option("date_format") — Datumformaat;
get_option("default_category") — Standaardcategorie;
get_option("siteurl") - WordPress URL (zie Opties -> Algemeen);
get_option("start_of_week") - Eerste dag van de week;
get_option("upload_path") - Standaard uploadmap (verouderd);
get_option("posts_per_page") - maximaal aantal berichten per pagina;
get_option("posts_per_rss") — Maximaal aantal berichten in de RSS-feed;

De meeste van de vermelde gegevenstypen zijn gespecificeerd in de WordPress-instellingen, op het tabblad ‘Opties’. De uitzonderingen zijn: “Site-codering” - direct aangegeven in de database en “Standaard downloadmap” - de optie is sinds versie 3.5 uit de instellingen verwijderd.

Waarom vertel ik dit allemaal? Feit is dat de inhoud van de bestanden in de sjabloon voor iedereen anders is, maar als je begrijpt wat erin staat en hoe het werkt, zal het veel gemakkelijker zijn om WordPress te optimaliseren en onnodige oproepen naar de database te verwijderen.

Ik zal je later vertellen hoe en wat je de functie get_option() moet vervangen, maar laten we nu eens kijken wat voor soort bloginfo() er in de code is geschreven in plaats van in het anker.

bloginfo() functie en serverbelasting

Laten we teruggaan naar het moment waarop de gebruiker de pagina opende. We hebben ontdekt dat de URL van de startpagina uit de database is gehaald met behulp van de functie get_option('home').

Oké, dus waar komt de titel zelf vandaan? De titel wordt ook opgeslagen in de database, maar in ons geval werd deze ontvangen en weergegeven door een andere functie: bloginfo().

Opmerking! bloginfo() is een sjabloontag die de functie get_bloginfo() inschakelt. Kan overal in de sjabloon worden gebruikt.

De bloginfo() functie kan de volgende parameters accepteren:

bloginfo("url") — Toont de site-URL;
bloginfo("naam") - Toont de naam van de site;
bloginfo("description") - Toont een beschrijving van de site;
bloginfo("template_url") - pad naar de huidige themamap;
bloginfo("template_directory") - hetzelfde als "template_url";
bloginfo("stylesheet_url") - pad naar de stylesheet van het huidige thema;
bloginfo("stylesheet_directory") - hetzelfde als "stylesheet_url";
bloginfo("charset") — Toont de sitecodering;
bloginfo("admin_email") — Toont het e-mailadres van de beheerder;
bloginfo("version") - Toont de WordPress-versie;
bloginfo("html_type") - Voert gegevens uit uit het html_type van de wp-optionstabel;
bloginfo("pingback_url") - pad naar het xmlrpc.php-bestand;
bloginfo("rss2_url") — Toont de URL van de RSS 2.0-feed (domein/feed);
bloginfo("comments_rss2_url") — Toont de URL van de commentaarfeed (domein/comments/feed);
bloginfo("rdf_url") — Toont de RDF-RSS 1.0-feed-URL (domein/feed/rfd);
bloginfo("rss_url") — Toont de URL van de RSS 0.92-feed (domein/feed/rss);
bloginfo("atom_url") — Toont de Atom-feed-URL (domein/feed/atom);

De functie bloginfo() verschilt enigszins van de functie get_option(), maar werkt volgens een soortgelijk principe, dat wil zeggen dat hij bepaalde gegevens uit de database opvraagt ​​en deze op het scherm weergeeft.

Het is de moeite waard om te zeggen dat er verschillende meningen zijn over de belasting in het noorden die wordt gecreëerd door de bloginfo() -functie. Maar de belasting bestaat zeker, en als er een mogelijkheid is om deze te verminderen, dan zou het zonde zijn om van deze mogelijkheid geen gebruik te maken.

Ik heb een hele reeks maatregelen genomen, waarna mijn blog ruim twee keer zo snel ging.

Bovendien gebruik ik geen cache-plug-ins of scripts, zoals MaxCache, en ben ik ook niet van hosting veranderd en ben ik trouw gebleven aan TimeWeb. Het resultaat werd alleen bereikt dankzij WordPress-optimalisatie. Trek dus uw eigen conclusies.

Natuurlijk hebben de maatregelen die ik heb genomen niet alleen betrekking op het verminderen van het aantal zoekopdrachten in de database, en ik zal je geleidelijk over alles vertellen, maar ik kan dit omvangrijke materiaal niet in één artikel proppen.

Verwacht dus nieuwe sweats gewijd aan de laadsnelheid van pagina's en abonneer je erop om ze niet te missen blog-updates.

Technologie voor het verminderen van databasequery's

Laat me je eraan herinneren hoe de headercode eruit ziet in mijn header.php-bestand:

/">

Nu komt het interessante deel. Als je naar de broncode kijkt, zal de headercode daar een heel andere vorm aannemen:

Dit is de headercode die in het header.php-bestand moet worden geschreven. Vervolgens verwijdert de server twee volledig onnodige verzoeken, vermenigvuldigd met het aantal geopende pagina's.

Maar waarom zijn de bovengenoemde functies dan in de sjabloonbestanden geschreven?

Feit is dat ontwikkelaars niet kunnen weten op welk domein de door hen gemaakte sjablonen vervolgens zullen worden gebruikt, en ze kunnen ook niet weten welke namen de sites zullen hebben. Daarom zijn universele functies ontwikkeld voor alle sjablonen die gegevens uit de database ontvangen.

Maar jij en ik kennen de naam van onze site en we kennen ook het domein. Het blijkt dat het niet nodig is om deze functies te gebruiken.

Daarom zoeken we, beginnend met het header.php-bestand, naar delen van de code met de bovengenoemde functies, kijken vervolgens hoe ze er in de broncode uitzien en vervangen ze.

Om het materiaal te versterken, zal ik verschillende voorbeelden geven. Hier is de code die de coderingsinformatie weergeeft.

; tekenset=" />

Laten we naar de broncode kijken:

We kopiëren de hele regel en plakken deze in plaats van de code met functies.

Code voor het verbinden van het style.css-bestand:

" type = "text/css" media = "scherm" />

Het pad naar het stijlblad wordt afgeleid met behulp van de functie bloginfo('stylesheet_url'). Laten we naar de broncode kijken:

/images/fav.ico" type="image/x-icon" />