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 motor, host/port (eller socket-sti), test forbindelsen, og bekræft “Connected”. Fejler status, er det næsten altid forkert host/port – eller at tjenesten slet ikke kører på serveren.

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 hundredvis af små databaseopslag. Det er dem, object cache fjerner – og derfor er den de dynamiske siders vigtigste hastighedsgreb.

Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026; menupunkternes navne kan variere mellem LiteSpeed Cache-versioner. Terminaleksemplet er genskabt.

Hvad object cache løser

Hver u-cachet sidevisning udløser typisk 50-200 databaseopslag: options, menuer, produkter, brugerdata. Mange af svarene er identiske fra visning til visning – og det er dem, object cache gemmer i RAM. Effekten: markant hurtigere wp-admin på indholdstunge sites, hurtigere checkout, hurtigere søgning og filtrering i WooCommerce, og lavere belastning på databasen under travlhed. Object cache erstatter ikke page cache – de arbejder i hver sin ende: page cache for de anonyme, object cache for alt det dynamiske.

Redis eller Memcached?

Begge løser opgaven, og på et enkelt WordPress-site er forskellen i praksis lille. Redis er i dag det almindelige valg: ét værktøj, bredt understøttet, med flere muligheder (persistens, flere databaser til flere sites). Memcached er enklere og glimrende, hvor det allerede er sat op. Det reelle valg står mellem, hvad din hosting tilbyder – spørg, om Redis er tilgængeligt på din pakke, og om forbindelsen sker via socket (hurtigst, samme server) eller host/port.

Opsætning i LiteSpeed Cache

1. Gå til LiteSpeed Cache → Cache → Object, og slå Object Cache til.
2. Vælg metode (Redis eller Memcached), og 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).
3. Har serveren flere sites på samme Redis, så giv hvert site sit eget databasenummer (Redis DB ID), så deres nøgler ikke blandes.
4. Gem, og tjek statusfeltet: Connected betyder i drift. Statussen kan også ses i terminalen:

Når status siger “failed”

• Tjenesten kører ikke: Redis/Memcached skal være installeret og startet på serveren – det er en hosting-funktion, ikke noget pluginnet kan starte. På Hostious-pakker med Redis aktiveres den i kontrolpanelet; spørg supporten, hvis du er i tvivl.
• Forkert host/port/socket: brug præcis den forbindelse, hostingen opgiver – en socket-sti slår host/port, når begge er udfyldt.
• Manglende PHP-udvidelse: PHP skal have redis- eller memcached-udvidelsen aktiv. Tjek under Værktøjer → Webstedstilstand → Info → PHP, eller slå den til i kontrolpanelets PHP-indstillinger.
• 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.

Verifikation

Object cachen gør sit arbejde, når status viser Connected, hit-tælleren stiger støt under brug, wp-admin føles mærkbart hurtigere på lister og søgninger – og en før/efter-måling af en u-cachet side (fx checkout) viser lavere TTFB. Husk én driftsregel: efter store dataændringer uden om WordPress (fx direkte databaseimport) skal object cachen tømmes, så gamle værdier ikke overlever – knappen ligger samme sted som opsætningen.

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; tøm cachen efter den slags, så er du dækket.

Hvor meget hurtigere bliver sitet?

På anonyme, cachede sider: ingenting – de rammer aldrig databasen. På dynamiske sider er 20-50 % lavere TTFB almindeligt, mest på sites med mange plugins, produkter eller brugere. Mål på din egen checkout – 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.

Læs også

• Hub: QUIC.cloud og LiteSpeed Cache
• Langsom checkout i WooCommerce
• Høj TTFB i WordPress
• LiteSpeed Cache-indstillinger
• LiteSpeed hosting hos Hostious