Webbhotell med Redis

Redis är en in-memory-databasserver som fungerar som ett blixtsnabbt cachningslager mellan din webbplats och den vanliga databasen. Istället för att varje sidvisning kräver tunga MySQL-förfrågningar kan Redis leverera data direkt från RAM-minnet.

För WordPress med WooCommerce, tunga plugins eller hög trafik kan Redis dramatiskt förbättra laddtiderna. Problemet är att Redis kräver en separat serverprocess och därför inte erbjuds av alla delade webbhotell. Här jämför du de som gör det.

Läs om hur vi testar och betygsätter

Webbhotell där Redis ingår - inte kostar extra

Objektcache med Redis avlastar databasen och märks mest på sidor som inte kan cachas, som inloggning och kassa. Hos Kinsta kostar Redis 100 dollar per månad och sajt som tillägg. De fem här har det inkluderat i priset, vilket är hela poängen.

Redis avlastar databasen och märks mest på inloggade sidor och kassor. Hos flera stora aktörer är det ett dyrt tillägg, så här listar vi dem där det ingår. Så gör vi bedömningen

  1. Redis i alla paket Testat av oss Betyg 4,80

    Oderland kör LiteSpeed Enterprise med Redis och Memcached i samtliga paket, från servrar i Göteborg, för 215 kronor i månaden. Ingen uppgradering krävs för att få objektcache. Det är fullt utrustat, men också listans dyraste ingång.

    Standard Från 196,00SEK per månad Samma pris vid förnyelse Till Oderland
  2. Redis från Prime-nivån Testat av oss Betyg 4,60

    Inleeds Prime #1 ger Redis och LiteSpeed för 149 kronor i månaden med svensk telefonsupport. Värt att veta är att Redis bara finns från Prime och uppåt. De billigare Standard och Special saknar objektcache, så uppgraderingen är en förutsättning.

    Prime #1 Från 149,00SEK per månad Samma pris vid förnyelse Till Inleed
  3. Redis och svensk support Granskat, ej testat Betyg 4,50

    Templ är en managerad WordPress-plattform med Redis och svensk telefonsupport för 155 kronor i månaden vid förnyelse. Till skillnad från Kinsta ingår objektcachen i priset. Paketet ger dock bara 5 gigabyte och en enda sajt.

    Micro Från 142,00SEK per månad Förnyas 155,00 SEK Till Templ
  4. Redis redan i startpaketet Granskat, ej testat Betyg 4,30

    HostUp har Redis redan i sitt billigaste paket, för 79 kronor i månaden vid förnyelse, med LiteSpeed och servrar i Älvsjö. Ingen uppgradering behövs. Haken är supporten: chatt och e-post finns, men ingen telefonlinje.

    Start Från 59,00SEK per månad Förnyas 79,00 SEK Till HostUp
  5. Redis på molnserver Granskat, ej testat Betyg 4,30

    Cloudways bygger in Redis i sin managerade molnserver för 14 dollar i månaden, med NVMe och SSH. Det passar den som vill styra cachen på servernivå. Supporten är på engelska och saknar telefon.

    Micro Från 14,00USD per månad Samma pris vid förnyelse Läs mer
Jämför alla webbhotell för Redis Öppnar jämförelsen med filtren redan satta

Priser anges exklusive moms i leverantörens egen valuta, och avser det paket som bäst uppfyller facettens krav. Baslinjen är ett års bindning delat med tolv.

Redis gör mest nytta där databasen är flaskhalsen

Redis är ett objektcache-lager som sparar resultaten av databasfrågor och beräknade värden direkt i serverminnet. I stället för att MySQL eller MariaDB ska besvara samma frågor om och om igen läser WordPress svaret från RAM, som är storleksordningar snabbare än en diskbaserad databas. Det låter tekniskt, men konsekvensen är enkel att förstå: sajten svarar snabbare, och databasen behöver inte slita lika hårt.

Märk att Redis inte ersätter sidcache eller OPcache. Det handlar specifikt om objektcache, det vill säga resultaten av PHP-funktionsanrop och databasförfrågningar som WordPress annars skulle repetera vid varje sidladdning. En sida som genereras av WordPress gör typiskt tiotals, ibland hundratals, databaskall. Med Redis sparas resultaten vid första anropet och återanvänds direkt ur minnet tills cachetiden löper ut eller innehållet ändras.

När Redis faktiskt gör skillnad

För en enkel blogg med statiskt innehåll och lite trafik märker du knappt att Redis är på. LiteSpeed eller en sidcache-lösning tar hand om det tunga lyftet långt tidigare i stacken, och objektcache adderar marginellt ovanpå det.

Bilden förändras drastiskt för WooCommerce-butiker. Kundvagn, kassa och kontosidor kan inte helsidecachas eftersom de innehåller användarspecifik information. Det innebär att PHP och databasen måste arbeta vid varje sidladdning i köpflödet. Här är objektcache via Redis den möjlighet som faktiskt återstår för att hålla svarstiderna nere. Liknande dynamik gäller sajter med inloggade användare, forum, avancerade sökfilterfunktioner eller webbplatser som aggregerar data från flera datakällor.

En annan signal på att Redis hjälper är en seg adminpanel. Om det tar tre till fyra sekunder att spara ett inlägg eller öppna en inställningssida beror det sällan på nätverket, utan på hur länge PHP väntar på databasen. Objektcache kan korta den väntetiden påtagligt.

Redis cachar databaskall i RAM. Sidcache kringgår PHP helt. Det är inte samma lager, och de kompletterar varandra.

Redis eller Memcached?

Båda är minnescachesystem, men de skiljer sig på ett par viktiga punkter. Memcached är avskalat och snabbt för enkla nyckel-värde-uppgifter. Redis är mer kapabelt: det stöder persistens (data överlever en omstart), komplexa datastrukturer som listor och mängder, och pub/sub-kommunikation. För WordPress-objektcache är den praktiska skillnaden inte dramatisk, men Redis har kommit att bli det klart vanligare valet hos webbhotell som erbjuder objektcache.

Viktigt när du utvärderar ett webbhotell är huruvida Redis-instansen är dedikerad per konto eller delad mellan flera kunder på samma server. En delad Redis-instans kan fungera, men minnesutrymmet konkurrerar med grannkontona, och en intensiv granne kan pressa ut ditt cacheddata. En dedikerad instans ger förutsägbar prestanda och är det enda rimliga valet för sajter med höga krav.

Redis och WordPress: det krävs ett plugin

Redis kommunicerar inte med WordPress automatiskt. Du behöver ett dropin-plugin som kopplar ihop de två. Det populäraste alternativet är Redis Object Cache av Till Krüss, som finns på wordpress.org. Pluginet installerar sig som en dropin i wp-content/, vilket innebär att det laddas tidigt i WordPress boot-processen, innan de flesta plugin ens startar.

Förutsättningen är att webbhotellet faktiskt exponerar Redis för ditt konto, antingen via en socket-fil eller via en lokal TCP-port, och att PHP-tillägget phpredis (alternativt Predis) är tillgängligt. Kontrollpanelen eller dokumentationen brukar ange om Redis finns aktiverat, men det är värt att fråga direkt om du är osäker. Finns inte phpredis-tillägget laddas pluginet ändå, men faller tillbaka på en långsammare PHP-implementation.

När allt är rätt konfigurerat syns statusen direkt i pluginets inställningspanel: ansluten, antal cachar träffar (hits) kontra missar, och hur mycket minne som används. En hög hit-rate på 80 procent eller mer tyder på att Redis verkligen avlastar databasen som det ska.

Kolla hit-raten efter aktivering

Installera Redis Object Cache-pluginet och låt det köra i ett dygn innan du dömer ut det. En hit-rate under 50 procent de första timmarna är normalt eftersom cacherna är tomma. Hit-raten stiger med trafiken. Om den efter ett par dagar fortfarande är låg är det ett tecken på att objektcache-TTL är satt för kort, eller att sajten genererar för många unika nycklar för att cachen ska hinna fyllas ordentligt.

Säger WordPress själv att du behöver Redis?

Innan du lägger tid eller pengar på en Redis-instans lönar det sig att ställa två frågor i rätt ordning. Behöver den här sajten det, och om du redan har aktiverat det, fungerar det faktiskt? WordPress-kärnan har ett eget svar på den första frågan, inbyggt i Webbplatshälsa. Den andra frågan besvarar kärnan sämre, för den gröna statusen mäter inte om cachen fungerar, bara om filen finns.

Har du passerat kärnans egen tröskel?

Sedan WordPress 6.1 avgör metoden WP_Site_Health::should_suggest_persistent_object_cache() om Webbplatshälsa ska föreslå beständig objektcachelagring över huvud taget. Förslaget dyker bara upp när minst ett av flera värden passeras, antingen 500 autoladdade rader (alloptions_count) eller cirka 100 kB autoladdad data (alloptions_bytes), alternativt 1 000 vardera i antal kommentarer, options, inlägg, termer eller användare. En multisite-installation föreslår alltid objektcache, oavsett storlek. Ligger du under samtliga trösklar visar Webbplatshälsa statusen "bra" med texten "Det är inte obligatoriskt att ha beständig objektcachelagring" (mer om tröskelvärdena hos developer.wordpress.org).

För en mindre svensk sajt är det sällan trafik eller antal inlägg som utlöser förslaget, utan just autoladdade options, alltså för många rader eller för mycket data i alloptions. Det är i praktiken ett symptom på plugin-svullnad snarare än ett bevis på att sajten vuxit ur sin databas. Rätt första åtgärd blir då att städa och trimma de autoladdade optionsraderna, inte att köpa en Redis-instans. Redis döljer symptomet. En rensning tar bort orsaken.

Ljuger den gröna bocken?

Även när tröskeln är passerad och du har aktiverat en cachelösning finns en andra fälla. WordPress sätter statusen "En lösning för beständig objektcachelagring används" enbart för att filen wp-content/object-cache.php existerar och definierar cache-funktionerna. Ingen anslutning kontrolleras. I pluginet Redis Object Cache faller dropinen tillbaka på en intern cache per förfrågan när Redis inte går att nå, och enligt utvecklarens egna kodkommentarer tvingas alla grupper då bli "no redis"-grupper. Resultatet kan bli att Webbplatshälsa visar grönt medan Redis i praktiken ligger nere och cachen töms vid varje ny sidladdning.

På delade webbhotell finns samma fälla i en annan form. Ett minnestak per konto för Redis är vanligt, och slås taket i, sätts inte nya nycklar. Dropinen fångar felet och faller tyst tillbaka precis som ovan. Databaslasten sjunker inte, men den gröna bocken står kvar orörd. Lita därför aldrig enbart på Webbplatshälsas status. Verifiera i stället i pluginets egen statuspanel, där anslutning, hits och missar visas, eller kör kommandot wp redis status från terminalen.

För mer om den bredare cachingbilden i WordPress-webbhotell, och hur Redis passar in bredvid sidcache och OPcache, finns en genomgång i vår guide om WordPress-hosting.

Vanliga frågor om Redis och webbhotell

Svar på de vanligaste frågorna om Redis-caching, när det hjälper och hur du aktiverar det.

Redis och WordPress

Redis fungerar som ett minne för WordPress databasfrågor. Utan Redis hämtar WordPress samma data från MySQL om och om igen vid varje sidladdning. Med Redis sparas resultaten av dessa frågor i RAM, och nästa anrop svarar på under en millisekund istället för att slå mot databasen. Det märks mest på dynamiska sidor som kundkorgar, inloggade vyer och sök, alltså sådant som en vanlig sidhanterings-cache inte kan lagra.

Installera insticksprogrammet Redis Object Cache (wordpress.org/plugins/redis-cache), ange din Redis-anslutning i wp-config.php via konstanterna WP_REDIS_HOST och WP_REDIS_PORT (vanligen 127.0.0.1:6379), och klicka sedan på Aktivera i insticksprogrammets inställningar. Håll isär två saker som lätt blandas ihop. Beständig objektcachelagring, som funktionen heter på svenska i WordPress, betyder att ett resultat överlever mellan sidladdningar så att nästa besökare kan återanvända det. Redis egen diskpersistens (appendonly yes) är något annat och avgör bara om innehållet finns kvar efter att Redis-tjänsten startats om. För en objektcache spelar det senare sällan någon roll, eftersom cachen är byggd för att kunna fyllas på igen. Du behöver alltså inte be webbhotellet slå på diskpersistens för att objektcachen ska fungera.

För en sajt med hundratals besökare per dag och statiskt innehåll ger Redis ingen märkbar skillnad. En vanlig sidcache som W3 Total Cache eller WP Super Cache löser det mesta för enkla bloggar och presentationssajter. Redis börjar ge faktisk utdelning när sajten har mycket dynamiskt innehåll, inloggade användare, en WooCommerce-butik, eller trafiktoppar som pressar databasen. Under den nivån är en välkonfigurerad sidcache den effektivare insatsen.

Redis i praktiken: när det hjälper och när det inte gör det

Redis ger störst effekt i tre situationer: WooCommerce-butiker med många produkter och varianter, sajter med ständigt inloggade användare som inte kan hanteras av sidcachen, och WordPress-installationer som kör tunga metafrågor eller sökfunktioner mot stora databaser. Det klassiska misstaget är att aktivera Redis på en sajt som redan hanteras av en effektiv sidcache. Om alla dina sidor levereras som statisk HTML har Redis ingenting att optimera.

Sidcache och Redis löser olika problem och kompletterar varandra snarare än konkurrerar. Sidcachen lagrar den färdiga HTML-sidan och svarar utan att PHP ens körs. Redis träder in för allt sidcachen inte täcker: inloggade användare, unika kundkorgar, sökresultat och wp-admin. En välskött sajt med hög trafik har ofta båda. En liten sajt klarar sig länge med bara sidcache.

En felkonfigurerad Redis-installation kan faktiskt försämra prestanda. Vanliga fallgropar är att Redis kör utan minnesgräns och börjar använda swap på disk, att TTL-värdena är för höga så gammal data serveras, eller att insticksprogrammet tappar anslutningen och faller tillbaka på databasanrop med extra overhead. På delad hosting begränsar dessutom webbhotellet ofta Redis-minnet per konto, vilket kan ge kastad cache vid toppar.

Redis vs Memcached och hosting-aspekter

Memcached är snabbare vid enkel nyckel-värde-lagring och klarar hög parallellitet tack vare sin flertrådsarkitektur. Redis stöder fler datatyper, kan konfigurera persistent lagring och ger bättre kontroll i komplexa scenarier. För en typisk WordPress-sajt är hastighetsskillnaden försumbar, de flesta webbhotell stöder Redis i dag snarare än Memcached, och ekosystemet av WordPress-insticksprogram är rikare kring Redis. Välj Redis om du inte har ett specifikt skäl för Memcached.

På delad Redis delar flera kundkonton på samma Redis-instans med ett gemensamt minnesutrymme. Det fungerar ofta bra vid normal trafik men innebär att ett grannsajt med trafiktoppar kan pressa ut din cache ur minnet. Dedikerad Redis innebär att instansen reserveras för ditt konto med garanterat minne och möjlighet att konfigurera TTL, maxminne och persistens efter dina egna behov. Skillnaden märks mest på butiker och sajter med hög trafik. Länge klarar de flesta sig med delad Redis om webbhotellet sköter isolering korrekt.

Delade webbhotell inkluderar Redis allt oftare, men det varierar kraftigt. Många svenska och nordiska webbhotell aktiverar Redis på begäran eller via ett kryssalternativ i kontrollpanelen, medan andra kräver att du uppgraderar till en VPS eller ett managed WordPress-paket. Kontrollera alltid att Redis är tillgängligt innan du väljer hosting, särskilt om du kör WooCommerce. På en VPS styr du Redis-konfigurationen fullt ut.