Object cache med Redis eller Memcached i LiteSpeed Cache

Kort svar: Object cache gemmer databasesvar i hukommelsen, så gentagne opslag ikke rammer databasen – gevinsten mærkes præcis dér, hvor page cache ikke gælder: wp-admin, checkout, søgning og indloggede brugere. I LiteSpeed Cache sættes den op under Cache → Object med Redis eller Memcached: vælg metode, angiv host og port (eller socket-sti), gem, og bekræft, at status står som „Connected“. Fejler status, er det næsten altid forkert host/port, en manglende PHP-udvidelse – eller at tjenesten slet ikke kører på serveren.

Fagligt gennemgået: 2. oktober 2026

Page cache gør de offentlige sider hurtige – men den hjælper ikke redaktøren i wp-admin, kunden i checkout eller den indloggede B2B-køber. Deres sider bygges forfra hver gang, med mange små databaseopslag. Det er dem, object cache fjerner – og derfor er den et af de vigtigste hastighedsgreb for de dynamiske sider.

Guiden forklarer, hvad object cache gør, hvordan du vælger mellem Redis og Memcached, hvordan du sætter det op i LiteSpeed Cache, og hvordan du fejlfinder og verificerer, at cachen faktisk rammer. Menupunkternes navne kan variere en smule mellem versioner af LiteSpeed Cache.

Før du ændrer noget: Tag en backup, og tjek under Plugins, om der allerede kører et andet object cache-plugin (fx Redis Object Cache eller W3 Total Cache med object cache slået til). Der må kun være én object-cache.php i wp-content, og to systemer om samme opgave giver konflikter.

Hvad object cache løser

Hver sidevisning, der ikke kommer fra page cache, udløser en lang række databaseopslag: indstillinger (options), menuer, produkter, brugerdata og metadata. På sites med mange plugins eller produkter kan der være tale om hundredvis af opslag pr. visning. Mange af svarene er identiske fra visning til visning – og det er dem, object cache gemmer i RAM.

WordPress har altid haft en intern object cache, men den lever kun i den enkelte request og glemmes, når siden er leveret. En persistent object cache, som Redis eller Memcached, gemmer svarene på tværs af requests. Derfor anbefaler WordPress’ Webstedstilstand (Site Health) også en persistent object cache på større sites.

Effekten mærkes typisk som:

• hurtigere wp-admin på indholdstunge sites, især lister, søgning og redigering;
• hurtigere checkout, kurv og Min konto i WooCommerce;
• hurtigere søgning og filtrering;
• lavere belastning på databasen under travlhed, fx ved kampagner.

Object cache erstatter ikke page cache – de arbejder i hver sin ende: page cache for de anonyme besøgende, object cache for alt det dynamiske. Læs mere om de forskellige lag i guiden om cachetyper.

Redis eller Memcached?

Begge løser opgaven, og på et enkelt WordPress-site er forskellen i praksis lille. Det reelle valg står oftest mellem, hvad din hosting tilbyder.

	Redis	Memcached
—	—	—
Datastrukturer	Mange (strenge, lister, hashes m.fl.)	Simple nøgle/værdi-par
Flere sites på samme instans	Kan adskilles med databasenummer (Redis DB ID)	Adskilles med nøglepræfiks
Persistens på disk	Mulig	Nej, kun hukommelse
Typisk brug i WordPress	Det mest udbredte valg i dag	Glimrende, hvor det allerede er sat op

Spørg din hosting, om Redis er tilgængeligt på din pakke, og om forbindelsen sker via socket (hurtigst, når Redis kører på samme server) eller via host og port. Valkey, som er et open source-alternativ udsprunget af Redis, taler samme protokol og sættes op på samme måde.

1. Tjek, at tjenesten og PHP-udvidelsen er klar

Object cache kræver to ting uden for WordPress: at Redis eller Memcached kører på serveren, og at PHP har den tilsvarende udvidelse (redis eller memcached) aktiv. Det er hosting-funktioner, som pluginnet ikke selv kan starte.

Har du terminaladgang, kan du teste Redis direkte. Svaret skal være PONG:

redis-cli ping
redis-cli -s /sti/til/redis.sock ping

PHP-udvidelsen kan du se i kontrolpanelets PHP-indstillinger eller med php -m i terminalen (kør den med samme PHP-version, som sitet bruger). Hos Hostious understøttes Redis object cache fra WP StartUp og skal aktiveres pr. site; se dokumentationen, eller spørg supporten, hvis du er i tvivl.

2. Slå object cache til i LiteSpeed Cache

1. Gå til LiteSpeed Cache → Cache, og vælg fanen Object.
2. Slå Object Cache til, og vælg metode: Redis eller Memcached.
3. Indtast forbindelsen: host 127.0.0.1 og port 6379 for Redis (11211 for Memcached) – eller socket-stien, hvis hostingen bruger en (fx /home/bruger/.redis/redis.sock). Ved socket sættes porten typisk til 0.
4. Kræver tjenesten login, så udfyld brugernavn og adgangskode.
5. Deler flere sites samme Redis, så giv hvert site sit eget databasenummer (Redis Database ID), så deres nøgler ikke blandes.
6. Gem, og tjek statusfeltet: Connected betyder, at cachen er i drift.

Statussen kan også ses i terminalen:

3. Vælg de rigtige indstillinger

Standardværdierne passer de fleste sites, men tre indstillinger er værd at kende:

• Default Object Lifetime: hvor længe et objekt må ligge i cachen. Standarden er fin; WordPress invaliderer selv nøgler, når data ændres.
• Persistent Connection: genbruger forbindelsen til Redis på tværs af requests og sparer lidt tid pr. visning. Slå den fra igen, hvis du ser forbindelsesfejl.
• Cache WP-Admin: cacher også opslag i wp-admin. Det giver typisk den største mærkbare forskel for redaktører, men kan i sjældne tilfælde vise forsinkede tal i plugins med egne statistikker. Test efter aktivering.

Felterne Global Groups og Do Not Cache Groups behøver du normalt ikke røre. De bruges, når et plugin dokumenterer, at bestemte cachegrupper ikke må gemmes, eller på multisite-installationer.

Når status siger „failed“

• Tjenesten kører ikke: Redis eller Memcached skal være installeret og startet på serveren. Test med redis-cli ping, eller spørg hostingen.
• Forkert host, port eller socket: Brug præcis den forbindelse, hostingen opgiver. En forkert sti eller en port, der ikke svarer, giver altid „failed“.
• Manglende PHP-udvidelse: PHP skal have redis– eller memcached-udvidelsen aktiv i den PHP-version, sitet kører på. Skifter du PHP-version, skal udvidelsen også være slået til i den nye.
• To object cache-systemer: Kører der også et Redis-plugin (fx Redis Object Cache), så vælg ét. To drop-ins om samme opgave giver konflikter.
• Rettigheder på socket-filen: Hvis PHP-brugeren ikke må læse socket-filen, fejler forbindelsen, selvom Redis kører. Det retter hostingen.

Sådan verificerer du

Object cachen gør sit arbejde, når:

• status i LiteSpeed Cache viser Connected;
• antallet af hits stiger støt under brug, mens misses flader ud;
• wp-admin føles mærkbart hurtigere på lister og søgninger;
• en før/efter-måling af en side uden page cache (fx checkout eller Min konto) viser lavere TTFB.

Med terminaladgang kan du følge hits og misses direkte, og med WP-CLI kan du se, hvilken object cache WordPress bruger:

redis-cli info stats | grep keyspace
wp cache type

Mål på dine egne dynamiske sider – ikke på forsiden, som normalt kommer fra page cache og derfor ikke ændrer sig. Brug fx Query Monitor til at se antallet af databaseopslag før og efter.

Husk én driftsregel: Efter store dataændringer uden om WordPress (fx direkte databaseimport eller søg-og-erstat i databasen) skal object cachen tømmes, så gamle værdier ikke overlever. Knappen ligger under LiteSpeed Cache’s værktøjer til at rydde cache, eller du kan bruge wp cache flush.

Rul tilbage

Giver object cache problemer, så slå den fra under samme fane og gem. Så holder LiteSpeed Cache op med at bruge Redis eller Memcached, og WordPress bruger igen kun sin almindelige, ikke-persistente cache. Sitet virker som før – bare uden gevinsten. Ligger der en gammel object-cache.php tilbage efter et tidligere plugin, så fjern den via SFTP, før du aktiverer LiteSpeeds løsning.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• Langsom checkout i WooCommerce
• Høj TTFB i WordPress
• LiteSpeed Cache-indstillinger
• Page cache, object cache og browser cache
• WordPress hosting hos Hostious – Redis object cache understøttes fra WP StartUp

Ofte stillede spørgsmål om object cache

Kan object cache give forkerte data?

Sjældent i normal drift – WordPress invaliderer selv nøglerne ved ændringer. Risikoen opstår ved ændringer uden om WordPress, fx en direkte databaseimport; tøm cachen efter den slags, så er du dækket.

Hvor meget hurtigere bliver sitet?

På anonyme sider, der kommer fra page cache: stort set ingenting – de rammer ikke databasen. På dynamiske sider afhænger gevinsten af, hvor mange databaseopslag siden laver, og er størst på sites med mange plugins, produkter eller brugere. Mål på din egen checkout eller wp-admin – ikke på forsiden.

Skal jeg vælge LiteSpeeds indbyggede eller et separat Redis-plugin?

Kører du LiteSpeed Cache i forvejen, så brug dens indbyggede – ét plugin, én opsætning, ingen drop-in-konflikter. Separate Redis-plugins er til sites uden LiteSpeed Cache.

Skal jeg bruge object cache på et lille site?

Et lille site med få plugins og få indloggede brugere mærker sjældent den store forskel, fordi de fleste sider alligevel kommer fra page cache. Har du WooCommerce, mange redaktører eller et langsomt wp-admin, er det derimod et af de første greb, du bør prøve.