Moderne browsers gebruiken vrij vaak een lokale cache in hun werk. Wat betekent dit? Dit betekent dat de browser, nadat hij een HTML-document, afbeelding of andere bron van de server heeft ontvangen, deze in zijn lokale cache plaatst (met andere woorden, de ontvangen bron naar de server schrijft). harde schijf gebruikersmachine) en tijdens daaropvolgende verzoeken aan een dergelijke bron geen toegang krijgt tot de server, maar de bron verkrijgt uit de lokale cache.
Dit browseralgoritme verhoogt de laadsnelheid van HTML-documenten dramatisch. Omdat als de bron al is geladen en zich als gevolg daarvan in de lokale cache bevindt, de toegangstijd niet wordt bepaald doorvoer communicatiekanaal (bijvoorbeeld modemverbinding) en de snelheid hard werken schijf.
Echter, samen met de voordelen deze methode brengt ook een aantal problemen met zich mee. Vooral de meeste beginnende webprogrammeurs worden bij het ontwikkelen van dynamische sites met hetzelfde probleem geconfronteerd. De essentie van dit probleem is dat in plaats van herhaaldelijk contact op te nemen met de server voor een pagina die een script op de server uitvoert dat bepaalde informatie wijzigt, de browser toegang krijgt tot de lokale cache. En als gevolg van bijvoorbeeld drie verzoeken zijn er niet drie wijzigingen in de informatie op de server, maar slechts één.
Om de browser te dwingen elke keer een pagina van de server op te vragen, moet u de browser de toegang verbieden deze hulpbron cachen. Hieronder staan de meest gebruikelijke methoden om caching uit te schakelen of te omzeilen.
Een nieuwe URL genererenLaten we aannemen dat de aangevraagde bron de volgende URL heeft: test.html?id=7. Zoals u aan de URL kunt zien, wordt er één parameter aan doorgegeven. Laten we bijvoorbeeld toevoegen wanneer JavaScript-hulp, er zit nog een parameter in de url, en we zullen er de waarde van maken willekeurig nummer. Als resultaat zal de url er als volgt uitzien: test.html?id=7&rnd=0.6700820127538827. De willekeurige parameter wordt elke keer opnieuw gegenereerd. Hieronder vindt u een lijst die deze aanpak demonstreert:
Een nieuwe URL genereren document.write("");
test link
Elke keer dat het resultaat van een dergelijk verzoek in de cache wordt opgeslagen, maar omdat de caching over de gehele URL wordt uitgevoerd, wordt er elke keer een nieuwe URL verkregen en wordt de browser gedwongen om een bron op te vragen bij de server, aangezien de URL's van de twee verzoeken komen niet exact overeen.
U kunt caching ook vanaf de serverzijde beheren. Om dit te bereiken, wordt de naar de browser verzonden bron vergezeld van headervelden. Gedetailleerde beschrijving headervelden zijn te vinden in de Rfc 2068-standaard, die beschrijft HTTP-protocol 1.1.
Verloopt kopveldDe waarde van deze header is de datum waarna de inhoud van de bron verouderd raakt. Als een gebruiker na deze datum toegang krijgt tot een bron, moet de browser de bron opvragen bij de server in plaats van bij de lokale cache.
Als het veld >Verloopt< содержит дату, прошедшую, по отношению к текущей, то при следующем обращении к ресурсу браузер будет вынужден снова обратиться к серверу. Это произойдет вследствие того, что либо документ не будет занесен в кэш — как уже устаревший, либо при обращении к кэшу браузер определит, что документ уже устарел. Следующий листинг на PHP демонстрирует использование заголовка Expires:
Laatst gewijzigd kopveldDe waarde van deze header is datum laatste update bron. Meerderheid moderne browsers gebruik volgende algoritme als de bron zich al in de lokale cache bevindt:
* vraagt van de server de datum van de laatste bronupdate op
* vergelijkt de ontvangstdatum en de brondatum in de lokale cache
* als de bron zich op de server bevindt nieuwer dan de bron in de cache - er wordt een bron opgevraagd bij de server
Als een bron op de server dit veld bevat huidige datum, dan zal de browser de bron elke keer bij de server opvragen, en niet bij de lokale cache. De volgende lijst demonstreert het gebruik van het kopveld Laatst gewijzigd:
header("Laatst gewijzigd: ". gmdate("D, d M Y H:i:s") . "GMT");
Cache-Control en Pragma-headerveldenEn tot slot de headervelden, die rechtstreeks verantwoordelijk zijn voor het cachen van bronnen. Het veld is gedefinieerd in de RFC 1945-standaard die het HTTP 1.0-protocol beschrijft. Dit veld wordt als verouderd beschouwd, maar in sommige gevallen is het nodig om het te gebruiken. In het bijzonder verwerken sommige proxyservers verzoeken voor voortdurend veranderende bronnen niet correct als dit headerveld niet samen met de bron wordt verzonden.
Het tweede veld is gedefinieerd in de RFC 2068-standaard, die het HTTP 1.1-protocol beschrijft. Met dit headerveld kunt u caching uitschakelen en elke keer een bron van de server opvragen. De volgende lijst demonstreert het gebruik van de headervelden Cache-Control en Pragma om caching uit te schakelen:
header("Cache-Control: geen cache, moet opnieuw valideren"); header("Pragma: geen cache");
Goed slecht
Het is geen geheim dat hoe sneller een site laadt, hoe handiger het voor gebruikers zal zijn. Als pagina's snel laden, zullen gebruikers uw site niet verlaten en zullen zoekmachines uw site beter behandelen. Voor veel moderne websites wordt de dynamische PHP-scriptuitvoeringsengine een knelpunt.
Nginx-webserver wanneer juiste instelling kan eenvoudigweg een groot aantal pagina's direct leveren, wat niet gezegd kan worden over het genereren van een pagina in PHP, dit kan enkele seconden duren. Maar PHP kan ook versneld worden door middel van caching. In dit artikel zullen we bekijken hoe PHP-caching is geconfigureerd, hoe het is en waarom het überhaupt nodig is. We zullen bijvoorbeeld een combinatie van php-fpm en Nginx gebruiken, maar de informatie uit het artikel is ook geschikt voor andere installatiemogelijkheden.
Het bijzondere van geïnterpreteerde talen is dat elke keer dat een script wordt gestart, de tolk het programma moet compileren en op fouten moet controleren. Maar we kunnen wel rondkomen. Er zijn twee hoofdtypen caching:
- Caching van kant-en-klare pagina's - de pagina wordt gegenereerd door PHP en vervolgens wordt de kant-en-klare pagina aan de gebruiker gegeven zonder toegang tot PHP. Ik zal je vertellen hoe je dit moet doen met behulp van fastcgi, maar ik raad het gebruik van deze methode niet aan voor Wordpress of andere zoekmachines. Het is beter om ze in de cache te plaatsen met behulp van speciale plug-ins;
- Bytecode en instructies in de cache opslaan - en dit is al interessant, niet de hele pagina wordt in de cache opgeslagen, maar slechts enkele instructies en stukjes bytecode die niet veranderen bij het aanroepen van het script. Voordat een script wordt uitgevoerd, moet de tolk het converteren naar een formaat dat hij begrijpt; een dergelijke conversie wordt alleen bij de eerste run uitgevoerd en vervolgens wordt de versie uit de cache gehaald;
- Sessiecaching - standaard slaat php gebruikerssessies op in bestanden en we kunnen het werk een beetje versnellen als we sessies in RAM opslaan.
Vanaf PHP 5.5 werd ondersteuning voor het cachen van bytecode van ZendFramework toegevoegd aan de taalinterpreter. In nieuwe versies kunt u met deze cache de prestaties van uw bron aanzienlijk verbeteren; er is bijvoorbeeld informatie dat Wordpres en andere zoekmachines bijna twee keer zo snel draaien op PHP 7. Voordat u opcode php-caching instelt, moet u het pakket installeren:
sudo apt installeer php-opcache
Of voor Rode Hoed distributies:
sudo yum installeer php-opcache
Om caching mogelijk te maken, moet je vervolgens een paar regels toevoegen aan php.ini, je kunt ook een apart bestand in /etc/php/conf.d/
vi /etc/php.d/opcache.ini
zend_extension=opcache.so;
opcache.error_log=/var/log/php-fpm/opcache-error.log
opcache.enable=1;
opcache.memory_consumption=256;
opcache.interned_strings_buffer=8;
opcache.max_accelerated_files=4000;
opcache.revalidate_freq=180;
opcache.fast_shutdown=0;
opcache.enable_cli=0;
opcache.revalidate_path=0;
opcache.validate_timestamps=2;
opcache.max_file_size=0;
opcache.file_cache= /var/www/site/opcache;
Laten we eens kijken wat deze lijnen betekenen, zodat u weet welke waarden u moet instellen. De eerste regel laadt de extensie, hier hoeft niets gewijzigd te worden.
- opcache.error_log - specificeert het bestand voor het vastleggen van het foutenlogboek, wat handig zal zijn bij het opsporen van fouten;
- opcache.log_verbosity_level - geeft aan hoe gedetailleerd het logbestand moet zijn, waarde van 1 tot 4;
- opcache.enable - maakt caching mogelijk;
- opcache.enable_cli - maakt caching mogelijk php-pagina's voor de consoleversie;
- opcache.memory_consumption - hoeveelheid RAM voor het opslaan van cache;
- opcache.max_accelerated_files - het aantal scripts/bestanden dat in de cache moet worden opgeslagen;
- opcache.validate_timestamps - controleer het tijdstip van gegevenswijziging in het scriptbestand;
- opcache.revalidate_freq - controleer de frequentie voor de vorige parameter;
- opcache.revalidate_path - ingesteld op 0 om alleen de eerste keer te controleren of include;
- opcache.enable_file_override - slaat verzoeken op voor bestandskenmerken, bijvoorbeeld bestaan, enz.;
- opcache.blacklist_filename - lijst met bestanden die niet in de cache hoeven te worden opgeslagen;
- opcache.max_file_size - maximale grootte scriptbestand voor caching, 0 - onbeperkt;
- opcache.interned_strings_buffer - toegestaan aantal strings in de buffer;
- opcache.fast_shutdown - gebruiken snelle manier geheugen vrijmaken.
Nadat u alle instellingen heeft opgeslagen, hoeft u alleen maar php of uw webserver opnieuw op te starten:
systemctl herstart php-fpm
Om er zeker van te zijn dat alles werkt, wilt u misschien zien welke scripts al in de cache zijn opgeslagen. U kunt hiervoor het opcache-statusscript gebruiken. Sla het script gewoon op in de map van uw webserver en geef het vervolgens machtigingen:
chmod 777 /var/www/site/opcode.php
http://localhost/opcache.php
Hier kun je het zien gedetailleerde statistieken voor caching, instellingen en hoeveelheid bezet geheugen.
Sessies opslaan in memcachedStandaard slaat php sessies op in bestandssysteem In sommige gevallen kun je behoorlijk versnellen php-taak, als u de opslag van sessies overzet van bestanden naar RAM, bijvoorbeeld memcached. Eerst moet je memcached en installeren php-bibliotheek ermee werken:
sudo apt install memcached php-memcached
Of voor op Red Hat gebaseerde systemen:
sudo yum installeer memcached php-memcached
Eerst moeten we memcached configureren, het bestand /etc/sysconfig/memcached openen en de regel CACHESIZE vinden. Hier moet je de hoeveelheid RAM opgeven die is toegewezen voor de cache:
vi /etc/sysconfig/memcached
session.save_handler = geheugencache
session.save_path = "tcp://localhost:11211"
Het enige dat overblijft is het opnieuw opstarten van uw PHP-interpreter:
systemctl herstart php-fpm
Als je wilt controleren of alles correct in de cache is opgeslagen en of er überhaupt iets in de cache staat, kun je phpmemcacheadmin gebruiken.
Fastcgi-pagina's in cache plaatsenIk raad het gebruik van fastgci-caching voor WordPress-sites niet aan, omdat er speciale plug-ins zijn die de cache nauwkeurig kunnen beheren, deze indien nodig kunnen wissen en op tijd kunnen bijwerken. Maar in alle andere gevallen kan de fastcgi-cache de site enorm versnellen. Het wordt geconfigureerd in de configuratie waar u fastgci inschakelt, bijvoorbeeld in de configuratie Nginx-webserver. De minimale manier om de fastgci-cache te configureren is door de volgende regels aan het serverblok toe te voegen:
vi /etc/nginx/vhosts/site.conf
fastcgi_cache_path /var/nginx/cache levels=1:2 key_zone=MYAPP:100m inactief=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
De eerste regel configureert verschillende parameters tegelijk. Ten eerste wordt het pad aan de cache toegevoegd. U kunt elk pad gebruiken, zolang de map maar bestaat en de webserver rechten heeft om ernaar te schrijven. De niveausrichtlijn specificeert hoeveel submappen er zullen zijn. Volgende regel geeft aan wat als sleutel voor de cache zal worden gebruikt. De sleutel wordt gehasht in md5.
Nu moet je het php-verwerkingsblok configureren:
locatie ~ \.php$ (
fastcgi_pass unix:/var/run/php7-fpm.sock;
fastcgi_index index.php;
omvatten fastcgi_params;
fastcgi_cache MIJNAPP;
fastcgi_cache_valid 200 60m;
}
Hier hebben we toegang tot de reeds geconfigureerde MYAPP-geheugenzone en specificeren we ook een cachelevensduur van één uur. Om de caching te controleren, kunt u de inhoud van de map bekijken:
ls -lR /var/nginx/cache/
Met deze methoden worden uw pagina’s veel sneller geladen. Als u php-caching wilt uitschakelen voor individuele pagina's, maak dan eerst de variabele no_cache met de waarde 0:
stel $no_cache 0 in;
Dan controleren wij vereiste parameters, en als deze overeenkomt, stelt u de waarde in op 1:
als ($request_method = POST)
{
stel $no_cache 1 in;
}
En om te eindigen geven we de waarde van deze variabele door aan de volgende richtlijnen, hierdoor wordt caching uitgeschakeld wanneer dit niet nodig is:
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
Het grootste probleem van caching is de reactiesnelheid op verzoeken aan de belangrijkste opslag- en verwerkingssystemen voor inkomend en uitgaand verkeer gestructureerde informatie.
Stel je voor wat er moet gebeuren snelle overdracht informatie, maar de snelheid van de gegevenstoegang is extreem laag. Of een andere situatie: de snelheid is goed, maar niet genoeg beschikbaar geheugenóf de kanaalbreedte is onvoldoende, óf processor- en schijffactoren verstoren de taak. In dit geval is caching de enige uitweg uit de situatie.
Soorten caching Caching (of cache) is een soort tussenbuffer waarin gegevens worden opgeslagen. Dankzij caching wordt de sitepagina niet voor elke gebruiker opnieuw gemaakt. Met caching kunt u ermee werken een groot aantal gegevens in de kortst mogelijke tijd en met beperkte middelen(server en gebruiker).Het is noodzakelijk om te begrijpen dat gegevens zowel aan de clientzijde als op de server kunnen worden verwerkt. Bovendien is de verwerking van servergegevens gecentraliseerd en heeft dit een aantal onbetwiste voordelen (vooral voor de ondersteunende dienst).
Er zijn verschillende soorten caching. Wij raden u aan elk type, de kenmerken ervan en de aanbevelingen voor gebruik te overwegen: 1. Browsercaching of clientcaching is een opdracht voor de browser om een bestaande in de cache opgeslagen kopie te gebruiken. De werking van een dergelijke caching is gebaseerd op het feit dat de browser bij een nieuw bezoek een 304 Not Modified-header krijgt en dat de pagina of afbeelding zelf wordt geladen vanuit de lokale browser. gebruikerscache. Het blijkt dat je verkeer bespaart tussen de browser van de bezoeker en de sitehosting. Dienovereenkomstig begint uw websitepagina sneller te laden. 1.1 Bestanden en afbeeldingen cachen Browsercaching is bij uitstek geschikt voor sites die groot aantal afbeeldingen: de afbeelding wordt niet elke keer gedownload wanneer u de site opent, maar wordt eenvoudigweg via de browsercache geladen.
Dit is het eerste cachingniveau, dat bestaat uit het retourneren van de header "verlopen" en titel "304 niet gewijzigd". Caching gedurende 2 weken wordt als het meest effectief beschouwd.
Echter, binnen in dit geval Er is belangrijke nuance: als de afbeelding op de site verandert, weet de browser dit niet onmiddellijk, maar alleen als u wacht op de vervaldatum of als u de cache in de browser zelf opnieuw instelt. Dit is niet erg efficiënt als het bestand voortdurend verandert en u het voortdurend moet bedienen huidige versie.
1.2 https-caching Speciale headers zoals strikte beveiliging. Zorgt ervoor dat de browser altijd toegang heeft tot het geselecteerde domein via https. Het bewaart deze status behoorlijk rigide en als dit type cache wordt geannuleerd, zal de browser nog geruime tijd blijven proberen de pagina via https te laden, terwijl de huidige headers worden genegeerd.1.3 Caching van de certificeringsinstantie De zogenaamde certificeringsinstantiestempel .Dit type Caching wordt als verplicht beschouwd als u niet wilt dat gebruikers van uw site wachten tot de certificeringsinstantie (dit is een bepaalde server die verantwoordelijk is voor de geldigheid van uw certificaat) het verzoek van de browser van de gebruiker heeft verwerkt en heeft bevestigd dat uw site inderdaad is erdoor goedgekeurd.
1.4 Paginacaching Zodra een pagina al is gegenereerd, moet u voortdurend de relevantie ervan in de gaten houden. Om dit te doen moet u een server-side cache gebruiken met wijzigingstijdregistratie afzonderlijke onderdelen pagina's (als de pagina is opgebouwd uit veel dynamisch gegenereerde blokken). Met deze aanpak bevat elk antwoord van de server speciale headers die het tijdstip aangeven waarop de pagina is gewijzigd, die vervolgens door de browser van de gebruiker worden verzonden wanneer de sitepagina opnieuw wordt bezocht. Wanneer de server dergelijke headers ontvangt, kunnen we analyseren huidige staat pagina (misschien zelfs weergeven), maar geef de titel in plaats van de pagina-inhoud "304 niet gewijzigd" waarvoor gebruikersbrowser betekent dat u de pagina vanuit uw cache (browser van de gebruiker) kunt weergeven.Natuurlijk is het mogelijk om de juiste headers te verzenden zonder gebruik te maken van cache-tracking op de server, maar in dit geval zullen de meeste gebruikers de update van de pagina-inhoud vrij laat ontvangen. Bij deze aanpak vraagt de browser soms de server om updates, maar de frequentie en regels voor elke browser worden geconfigureerd door de ontwikkelaar, dus er is geen hoop dat uw gebruikers updates op tijd zullen ontvangen.
Normaal gesproken wordt de cache verdeeld op gebruikerstype:
Deze verdeling is te wijten aan het unieke karakter van de inhoud voor elke geautoriseerde gebruiker en de gemeenschappelijkheid van de inhoud voor gastgebruikers. Op de meeste sites kan een ongeautoriseerde gebruiker de inhoud van de site niet wijzigen en dus de inhoud ervan beïnvloeden.
Met de browsercache kunt u verkeer en tijd besparen die u besteedt aan het laden van pagina's. Maar om het besparingseffect te bereiken, moet de gebruiker onze pagina minstens één keer bezoeken, wat betekent dat de belasting wordt ingeschakeld serverbronnen zal afnemen, maar niet significant.
2. Servercaching Servercaching verwijst naar alle soorten caching waarin gegevens worden opgeslagen serverkant. Deze gegevens zijn niet beschikbaar voor clientbrowsers. De cache wordt gemaakt en opgeslagen op een één-op-veel-basis (veel zijn in dit geval clientapparaten).
Misschien heeft iedereen wel eens gedroomd van een website die op pingsnelheid of sneller draait.
Maar dit type cache heeft ook zijn nadelen: bijvoorbeeld het onvermogen om pagina's in de cache op te slaan voor een geautoriseerde gebruiker, of een gebruiker wiens pagina-inhoud afhangt van de huidige variabelen van de gebruiker.
Gebruik deze cache als de server alle statische statussen van externe gegevens kent, zoals: uri, get (zonder aanvullende parameters), is de gebruiker niet ingelogd - dat wil zeggen dat dit in feite de ideale paginastatus is voor gastgebruikers. Houd rekening met het feit dat bij dergelijke caching de architectuur van de site of applicatie binnenkomende verzoeken altijd op dezelfde manier moet verwerken en hetzelfde type antwoorden moet geven. Deze status bestaat in elke applicatie of website; u hoeft deze alleen maar te volgen en er een cache op toe te passen.
In sommige noodgevallen wordt het cachen van hele pagina's meestal gebruikt, terwijl de paginacache van tevoren wordt opgeslagen opgegeven tijd(vanaf 2 minuten), waarbij de reacties van de server van hetzelfde type zijn (laat de browser dit niet in de cache opslaan).
2.2 De resultaten van het compileren van php-bestanden in cache opslaan Er wordt onderscheid gemaakt tussen pure codecompilatie en de optimalisatie ervan tijdens het compileren (scriptvervanging). Meest levendige voorbeelden:Beide soorten caching kunnen in een project worden gebruikt, maar elk heeft zijn eigen nuances waarmee rekening moet worden gehouden bij het schrijven van code.
Het is noodzakelijk om het volgende te controleren: de status van de tabellen, de status van de gebruikerssessie, of caching tijdens POST moet worden uitgeschakeld of KRIJG verzoeken(http-query), afhankelijkheid van het huidige adres, persistentie van caching (wanneer eerdere omstandigheden veranderen) of de dynamische aanpassing ervan.
Het cachen van individuele blokken pagina's is beter dan andere soorten caching als u bijvoorbeeld het aantal databaseverzoeken van echte (geautoriseerde) gebruikers wilt verminderen. Trouwens, met correct gespecificeerde afhankelijkheden zal het zelfs efficiënter werken dan alle volgende soorten caching.
Waarom is dit soort caching zo belangrijk? Het punt is dat het uitbreiden van de pool van databaseservers een veel moeilijkere taak is dan het uitbreiden van de pool van servers voor het PHP-gedeelte van de site. Bovendien zijn conflicten met de PHP-cachestatus veel gemakkelijker op te lossen dan conflicten bij het werken met meerdere databases.
U komt toch regelmatig een situatie tegen waarin u nieuw materiaal moet indienen waarvan de publicatiedatum al is toegestaan door de huidige tijdstempel? Simpel gezegd,
WAAR show_ts
