Er is de laatste tijd veel over gezegd de voordelen van statische sites . Maar in veel situaties is een dynamische aanpak een noodzaak. Of het nu gaat om een content management systeem, een customer relationship tool of een online winkel, ze stellen eindgebruikers in staat om complexe sites snel en consistent te onderhouden. En wanneer ze op de juiste manier worden samengesteld, kunnen ze statische sites vergelijken voor snelheid.
elke toepassing die vaak gegevens moet lezen en schrijven, zal een merkbare vertraging veroorzaken
Welk systeem u ook gebruikt, dynamische sites bestaan meestal uit vergelijkbare elementen. Dit zijn een vorm van een webserver, een backend en een applicatie, geschreven in een of meer programmeertalen. Deze combinatie van componenten biedt een grote mate van flexibiliteit, maar elk draagt zijn eigen overhead en verhoogt de laadtijd, iets dat alle moderne websites willen vermijden. Dit geldt met name voor databasetoegang: elke toepassing die vaak gegevens moet lezen en schrijven, zal een merkbare vertraging veroorzaken.
Dit helpt bij het gebruik van caching en een geschikte cachingstrategie voor uw gebruik. Het basisdoel van caching is om onnodig veelvuldig bellen tussen de applicatiedatabaselagen te voorkomen en in plaats daarvan vooraf gegenereerde statische HTML-pagina's te gebruiken, die veel sneller worden weergegeven in een browser.
De eerste cache die een internetgebruiker zou hebben opgemerkt, is de cache in zijn browser. Hoe vaak hebben ontwikkelaars je gevraagd om een "force-refresh" uit te voeren om wijzigingen te zien? Browsercaches zijn eenvoudig, maar een goed startpunt om te beginnen met het uitleggen van concepten voor caching. Een browser slaat representaties op van webpagina's die op de computer van een gebruiker worden bezocht en deze meestal één keer per sessie bijwerken als er veranderingen worden gedetecteerd of geforceerd door de site.
Een algemene tool die wordt gebruikt door site-eigenaren en beheerders is een 'omgekeerde proxy-cache' die zich bevindt tussen pagina-aanvragen die door een webbrowser en de webtoepassing worden ingediend. Het onderschept verzoeken en maakt kopieën van pagina's rechtstreeks uit de cache, waardoor een merkbare snelheidsboost wordt geboden.
Er zijn verschillende belangrijke proxy-cache-opties beschikbaar voor zelfinstallatie of als 'Software as a Service'. (We negeren cloudhostingproviders die doorgaans alles wat u nodig heeft, verpakken in een onafhankelijke webstack.)
Populaire proxy cache-opties zijn onder andere:
SaaS-opties voor caching liggen over het algemeen in de wereld van Content Delivery Networks (CDN's), die in plaats van een cache te plaatsen tussen een gebruiker en een webstack, gebruikerssets met gecachte inhoud die geografisch het dichtst bij hen zijn, dienen. Het is een subtiel verschil, maar een verschil dat voor grote sites met een wereldwijd publiek een groot verschil kan maken.
Vernis is beschikbaar in alle Linux-pakketbeheerders, lees als een Docker-afbeelding en vele andere opties de project-installatiepagina voor meer details.
Varnish slaat een standaardconfiguratiebestand op op /usr/local/etc/varnish/default.vcl of /etc/varnish/default.vcl , geschreven in VCL (Vernisconfiguratietaal). Dit configuratiebestand wordt gecompileerd in een klein programma via een C-interpreter om de snelheid nog meer te verhogen.
Afhankelijk van hoe je Varnish hebt geïnstalleerd, ziet het configuratiebestand er ongeveer zo uit:
backend default {.host = "127.0.0.1";.port = "8000";}Op zijn eenvoudigst definieert dit de standaardbackend gebruikt door Varnish, waarbij de host en de poort worden gedefinieerd waarnaar het moet luisteren en de inhoud onderscheppen.
Een handig kenmerk van Varnish is controleren met vooraf gedefinieerde intervallen als een backend nog steeds gezond is. Het heet 'Backend Polling' en wordt geconfigureerd door een sonde-gedeelte toe te voegen aan de backend-verklaring:
.probe = {.url = '/';.timeout = 34ms;.interval = 1s;.window = 10;.threshold = 8;}Het bovenstaande zijn de standaardinstellingen die worden geboden door Varnish en vertellen dat het een bepaald .url -interval moet bezoeken en dat als de minimumdrempel uit .window- probes komt, de URL binnen .timeout milliseconden reageert, de backend nog steeds als gezond wordt beschouwd. Zodra het als 'ongezond' wordt beschouwd, wordt de inhoud voor een vooraf gedefinieerde periode uit de cache geserveerd.
We zullen specifieke wijzigingen in de Varnish-configuratie onder elke platformoptie behandelen, want laten we nu de algemene opties bekijken.
ports
Aanvankelijk zal de poort voor uw webserver moeten veranderen van de standaard. In de Apache Vhost-configuratie wijzigt u bijvoorbeeld de poort in 81 of 8080.
Start de Varnish-daemon met de vernisopdracht of met een servicewrapper. De daemon heeft vlagopties, de meest voorkomende en nuttige zijn:
Alles controleren werkt
Voer de opdracht varnishstat uit of bezoek isvarnishworking.com om te controleren of uw Varnish-server gereed is en naar verzoeken luistert.
Wat niet te cachen
Er zijn bepaalde delen van een site die we niet willen cachen, bijvoorbeeld de beheerpagina's. We kunnen ze uitsluiten door een vcl_recv- subroutine te maken in het bestand default.vcl met een if- instructie die bepaalt wat niet in de cache moet worden gezet:
sub vcl_recv {# URI of admin folderif (req.url ~ "^/url/"){return (pass);}return(lookup);}Als u Vernis 4 gebruikt, zijn de zaken iets anders, inclusief retourwaarden. De functie vcl_recv retourneert nu de ahash- waarde in plaats van een zoekopdracht.
sub vcl_recv {...return(hash);}Dit is ook waar we sites of subdomeinen instellen die Varnish moet negeren door een req.http.host ~ 'example.com' toe te voegen aan de if- instructie.
koekjes
Standaard verbergt Varnish geen inhoud van de backend die cookies instelt. Evenzo, als de client een cookie verzendt, zal het Varnish rechtstreeks naar de backend omzeilen.
Cookies worden vaak door sites gebruikt om gebruikersactiviteit bij te houden en gebruikersspecifieke waarden op te slaan. Over het algemeen zijn deze cookies alleen van belang voor de client-side code en zijn ze niet van belang voor de backend of Varnish. We kunnen Varnish vertellen om cookies te negeren, behalve in bepaalde delen van de site:
if ( !( req.url ~ ^/admin/) ) {unset req.http.Cookie;}Deze if- instructie negeert cookies tenzij we zich in het admin-gedeelte van de site bevinden, waar het doorgeven van cookies van meer nut kan zijn (tenzij u sitebeheerders echt wilt frustreren).
Andere uitzonderingen
Bij een standaardinstallatie worden wachtwoordbeveiligde pagina's, GET- en HEAD-verzoeken niet door cache ingesloten.
We zullen nu kijken naar twee perfecte use cases voor Varnish: Drupal en Magento. Beide zijn zeer dynamische systemen waarmee niet-technische gebruikers een breed scala aan complexe taken kunnen uitvoeren. Dit kan leiden tot het laden van databasepagina's - zware pagina's en drukke sites worden merkbaar traag. Typische pagina's die met deze systemen zijn gemaakt, bevatten een mix van inhoud die zelden en vaak wordt bijgewerkt.
Drupal heeft standaard cacheopties die vergelijkbare functies uitvoeren als Varnish, maar biedt niet de flexibiliteit of snelheidsverhogingen die vereist zijn door grotere of complexere sites.
Op ware Drupal-wijze is er een module voor het verwerken van vernisintegratie om een deel van de hierboven beschreven handmatige configuratie op te slaan.
Installeer de module en zorg ervoor dat u de installatie-instructies in het Read Me- bestand van de module volgt.
Zorg ervoor dat het bestand / etc / default / varnish de volgende daemon-opties bevat (en de inspringing is belangrijk):
DAEMON_OPTS="-a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s file,/var/lib/varnish/$INSTANCE/varnish_storage.bin,128M"Zorg ervoor dat Apache en alle bijbehorende virtuele hosts op poort 8080 luisteren, niet 80. Start beide services opnieuw nadat u deze wijzigingen hebt aangebracht.
U moet mogelijk een 'Vernisbesturingssleutel' instellen op de moduleconfiguratiepagina. Zoek uit wat die sleutel is met de kat / etc / varnish / secret- opdracht en plak deze in de instellingenpagina. Selecteer de juiste vernisversie, sla de instellingen op en zie een aantal groene vinkjes onderaan de pagina.
De Varnish-module werkt samen met de standaard Drupal-cache-instellingen, dus zorg ervoor dat u die hebt ingeschakeld en geconfigureerd voor uw gebruik.
Voer varnishstat uit vanaf de opdrachtregel, begin met het navigeren door de site als een anonieme gebruiker en je zou stats zien veranderen in de opdrachtuitvoer.
Een van de paden die we niet willen cachen in Drupal zijn de admin-pagina's, we kunnen dit doen met een subroutine vcl_recv :
sub vcl_recv {# URI of admin folderif (req.url ~ "^/admin/"){return (pass);}unset req.http.Cookie;return(lookup);}U kunt overwegen om gebruikerspagina's, systeemupdates en andere pagina's die zijn gegenereerd door zeer dynamische modules zoals vlag die veel gebruikmaken van ajax om te werken, niet te cachen (ingelogd). Doe dit door verdere parameters req.url toe te voegen aan de if- instructie.
Een standaardinstallatie van Magento wordt geleverd met een intern cachingsysteem dat statische versies van site-elementen in een specifieke map opslaat. De pagina Systeem -> Cachebeheer geeft een overzicht van de huidige cachestatus en laat u alle of individuele componentcaches wissen. U kunt geaggregeerde CSS- en JS-bestanden en automatisch gegenereerde afbeeldingsbestanden van deze pagina wissen.
De komende versie 2 van Magento ondersteunt standaard Varnish-caching, maar voor nu moeten we gebruik maken van plug-ins van derden, ik raad de Terpentijnmodule . Zorg ervoor dat u de leesmij-bestand van het project omdat het enkele extra configuratiestappen noteert, kan het negeren ervan uw site doorbreken.
De Turpentine-module is in hoge mate configureerbaar en zal de nodige wijzigingen aanbrengen in vcl- bestanden en Varnish-configuratie voor u. Enkele belangrijke opties om in te stellen zijn:
De Turpentine-module wordt gekoppeld aan de standaard Magento-cache, dus het wissen van caches op de Varnish-cachepagina wist de relevante Varnish-caches.
Afgezien van het gebruik van Varnish met een van de dynamische systemen hierboven, zijn hier een handvol andere diverse tips die de cache-mogelijkheden van elke site zullen helpen.
Als u dezelfde inhoud in verschillende contexten gebruikt, moet deze dezelfde URL gebruiken. Meng bijvoorbeeld het gebruik van article.html , article.htm en artikel niet , hoewel uw CMS dit mogelijk toestaat. Dit zal leiden tot drie verschillende versies in de cache van dezelfde inhoud.
Zoals we hierboven zagen, zijn cookies moeilijk te cachen en zijn ze zelden zo noodzakelijk als we denken. Probeer het gebruik en het aantal ervan te beperken tot dynamische pagina's.
Het laden van siteactiva kan een van de meest tijdrovende onderdelen van een paginaversie zijn en er zijn eenvoudige tips om deze belasting te verminderen:
Het gebruik van CSS Image sprites voor iconografie in plaats van meerdere kleine bestanden resulteert in minder netwerkverkeer.
Het lokaal hosten van CSS- en JavaScript-bibliotheken betekent minder netwerkverkeer en meer controle over cachingstrategieën. Dit kan een toename van de onderhoudsoverhead betekenen om deze assets up-to-date te houden. Sla deze items op in mappen met een consistente naam, zodat verwijzingen ernaar ook consistent kunnen zijn.
Ik hoop dat deze introductie bij het versnellen van uw dynamische sites met caching nuttig was. De prestatiewinst is een eerste periode van configuratie, experimenten en aanpassingen waard. In dit tijdperk van korte aandachtsspanne en ongeduld, kan elke snelheidsversterking die je uit je set-up kunt persen het verschil maken voor je gebruikers en competitie.
Uitgelichte afbeelding, netwerk cache afbeelding via Shutterstock.