Kort fortalt: APCu lå øverst på alle målinger med 23 % flere forespørgsler pr. sekund og 18 % kortere svartid ved 50 samtidige brugere. Docket Cache lå bemærkelsesværdigt tæt efter. Redis, branchestandarden, gav kun 4,4 % flere forespørgsler pr. sekund. Se alle resultaterne.
WordPress er en fantastisk blogmotor og kommer med et væld af gode udvidelser, der lader dig forme WordPress til alt det, dit hjerte begærer. Fordi plugins skal rette sig efter WordPress’ eksisterende databaseskema og adgangsmønstre, bliver databasen ofte en flaskehals, når platformens skalerbarhed og ydeevne skal optimeres. Det gælder især for WooCommerce-webshops.
Bare det at slå pluginet til kan fordoble indlæsningstiden for din forside, og gud forbyde, at du installerer et par WooCommerce-plugins oven i.
Når vi optimerer webshops, er object cachen et af de første værktøjer, vi griber efter. Den cacher databasekald, og bredden og opfindsomheden i de metoder, forskellige plugins gør det på, er virkelig interessant. Den klassiske metode er at koble WordPress til Redis, og så er du færdig. Men hvad gør du, hvis du er på en server uden Redis, eller hvis du er kunde hos Kinsta, hvor Redis-tilvalget koster 100 dollar pr. site om måneden?1
Tja, verdenen af alternative object cache-plugins åbner et helt nyt kaninhul. Implementeringerne spænder fra at gemme objekter i hukommelsen med gode gamle APCu til en særligt bygget SQLite-database eller PHP-filer.
I denne artikel benchmarker vi en række meget forskellige object cache-implementeringer og ser, hvordan de klarer sig mod hinanden. Vi benchmarker følgende plugins: SQLite Object Cache, atec Cache APCu, Redis Object Cache og Docket Cache.
Benchmark
Eksperimentet er designet til at stressteste en WordPress-installation med forskellige grader af simulerede samtidige brugere.
Et K6-script køres flere gange med et varierende antal VU’er (virtuelle brugere). Benchmarken køres 3 gange for hvert antal VU’er, og medianen af kørslerne bruges som resultat.
Benchmarken tester med 5, 10, 25, 50, 100 og 200 VU’er. Testen fejlede hver gang ved 100 VU’er og derover, fordi serveren begyndte at afvise forespørgsler ved den mængde.
WordPress-opsætning
Eksperimentet bruger WordPress 7.0.0 og WooCommerce 10.7 med Nginx + PHP-FPM med 5 PHP-processer, der kører PHP 8.3, alt sammen i Docker-containere.
Alle sider serveres uden cache. Kun en standardinstallation af WooCommerce med de 9 standard-eksempelprodukter kører ved siden af det plugin, der testes.
Server
Alle benchmarks blev kørt på en Linux-server med Ubuntu Server 26.04 LTS, en AMD Ryzen 3 PRO 4350G (4 kerner / 8 tråde), 16 GB DDR4-hukommelse og NVMe SSD-lager.
Moderne computere er hurtige. Virkelig hurtige. De kan lave millioner af beregninger i sekundet, og beregningerne bruges til at læse data fra disken, behandle dem til noget brugbart, som HTML’en til en hjemmeside, og så vise det for brugeren (for en hjemmeside: sende det til brugeren over internettet). Enkelte beregninger tager nanosekunder, men når du kæder dem sammen, løber det op. Oven i det: Hvis du beregner det samme igen og igen, er det MEGET hurtigere bare at gemme resultatet et sted og bruge det gemte resultat fremover.
Stedet, hvor du gemmer dit resultat, er en cache. Der findes caches overalt i computersystemer, hele vejen fra CPU’en til webserveren, der serverer denne side, og de gør beregningerne markant hurtigere, uanset hvor de sidder.
Object caches kan teknisk set gemme mange typer data, men når det gælder WordPress, WooCommerce og denne artikel, er en object caches vigtige funktion at gemme ting, der er hentet fra databasen. Det sparer os for meget dyre databasekald, som ofte står for langt størstedelen af den tid, en webshop bruger på at generere en side.
WordPress’ object cache
Udviklerne har bygget en object cache-grænseflade ind i WordPress, og den sender alle databasekald gennem sit object cache-lag. Som standard er der ingen object cache, og alle kald gennem laget går direkte til databasen. I så fald gemmes funktioner som menu-caching, transients og sessioner også i databasen. I WordPress styres object cachen gennem en grænseflade, som ethvert plugin kan implementere. Plugins erstatter blot filen object-cache.php med deres egen implementering af en object cache, og så klarer WordPress resten.
Redis Object Cache
Redis er branchestandarden for object caching generelt og den implementering, de fleste hostingudbydere tilbyder. Det er et datalager i hukommelsen, der kører i et separat program. Det betyder, at data cachet med Redis overlever mellem forespørgsler og kan deles på tværs af mange PHP-processer, modsat APCu.
En delt cache som denne har en pris: Hver læsning og skrivning i cachen kræver kommunikation med en anden proces, enten over TCP eller Unix-sockets, og det lægger netværksoverhead til forespørgslerne. Det kan afhjælpes ved at køre Redis på samme maskine som WordPress, men netværksforsinkelsen kan ikke fjernes helt.
atec Cache APCu
APCu (APC User Cache) er den moderne afløser for APC (Alternative PHP Cache). APC cacher PHP-bytekode og giver en delt cache i hukommelsen til brugerdata. Efter at opcode-caching blev en del af PHP’s kerne med PHP 5.5 og Zend OPcache, kom APCu. APCu er en version af APC uden bytekode-caching, så tilbage står den delte brugercache.2
atec Cache APCu er en drop-in-implementering af APCu til WordPress, som både har en object cache og en sidecache. I dette eksperiment bruger vi kun object cachen. atec hævder at være hurtigere end Redis med en forbedring på 16,67 %.3
atec har en pro-version af pluginet med understøttelse af PHP-arrays samt serialize() og unserialize().
SQLite Object Cache
SQLite er en filbaseret database, som programmer ofte bruger som lokalt lager, der er nemt at sætte op. SQLite er ikke bare nem at bruge, den har også meget god læseydelse og intet netværksoverhead. SQLite Object Cache er helt speciel, fordi den bruger en rigtig database som datalager for object cachen. Det kan lyde bagvendt, når vi prøver at mindske antallet af databasekald, men SQLite læser så hurtigt, at det faktisk giver mening. SQLite klarer sig dårligere med samtidige skrivninger, fordi den ikke understøtter parallelle skrivninger. Heldigvis bliver caches mest læst, så vi vil nok stadig se denne implementering klare sig godt. Kort sagt sender SQLite Object Cache databasearbejdet videre til en meget hurtigere database.
SQLite Object Cache kræver, at servermiljøet har udvidelserne sqlite3 og igbinary. Den kan også bruge APCu til at gøre cachen hurtigere. Vi tester pluginet både med og uden APCu slået til.
Docket Cache
Docket tilbyder både en object cache og nogle af de mere “almindelige” optimeringer, som at slå emojis, RSS-feeds osv. fra. Vi fokuserer kun på Dockets object cache. Og her har Docket en ret snedig object cache.
Docket omdanner bogstaveligt talt objekterne til ren PHP-kode og gemmer dem som filer på disken.4 Selvom fil-I/O lægger tid oven i svartiden, skærer det stadig ned på databaseforespørgslerne. Endnu bedre: Har du OPcache slået til, bliver indholdet af PHP-filerne cachet i OPcache, så det går meget hurtigt at hente dem. Det betyder også, at cachen virker i de fleste hostingmiljøer, fordi den ikke afhænger af eksterne biblioteker eller programmer.5
Det bliver interessant at se, om Docket Cache bliver begrænset af den tid, det tager at skrive og læse filer. Det går ikke hurtigt at læse filer, så det kan logisk set virke som en underlig løsning at gemme cache-objekter som filer.
Resultater
For at teste, hvordan hvert plugin klarer sig, har vi kørt en række benchmarks. Metoden kan du se i metodeafsnittet. Resultaterne viser, at alle object cache-plugins giver mærkbare forbedringer af svartid og kapacitet. Troede du, at gode gamle Redis var den mest effektive, vil resultaterne overraske dig.
Ser man på resultaterne, er det tydeligt, at alle cache-implementeringerne øger kapaciteten mærkbart. Ved 5 samtidige brugere måler vi 18,76 forespørgsler pr. sekund uden cache og 23 forespørgsler pr. sekund med APCu. De andre implementeringer ligger tæt på APCu, men Redis skiller sig ud med kun 19,82 forespørgsler pr. sekund.
Mønstret gentager sig ved alle antal samtidige brugere, og vi når en maksimal kapacitet på 28,97 forespørgsler pr. sekund ved 50 samtidige brugere.
P90-svartiderne ved 5 samtidige brugere er lidt mere nuancerede. Her ser vi en svartid på 251 ms uden cache og 216 ms for den hurtigste. Her kan vi se effekten af lagringsmediet. Redis, et helt separat program, er langsomst, mens Docket, SQLite + APCu og APCu, der bruger lagring i hukommelsen, er hurtigst. Det er interessant, at ren SQLite ligger midt imellem, men det giver mening, at et databaselag oven på filsystemet giver lavere ydeevne end Docket, der bruger både filsystemet og OPcache.
Forbedring ved 50 samtidige brugere
Ved 50 samtidige brugere er alle PHP-processer fuldt optaget, og forespørgslerne står i kø og venter på at blive behandlet. Det er her, object caches bør skinne, fordi hver proces bruger mindre tid på en forespørgsel. Her bliver forskellene mellem implementeringerne meget tydeligere, og vi bruger disse målepunkter som vores mål for forbedringen.
Kapacitet
| Forespørgsler/s | Forbedring | |
| Uden cache | 23,539 | 0,00 % |
| APCu | 28,975 | 23,10 % |
| SQLite | 27,166 | 15,41 % |
| SQLite + APCu | 27,791 | 18,07 % |
| Docket | 28,613 | 21,56 % |
| Redis | 24,586 | 4,45 % |
Svartid
| Svartid (ms) | Forbedring | |
| Uden cache | 2156,157 | 0,00 % |
| APCu | 1759,120 | 18,41 % |
| SQLite | 1876,854 | 12,95 % |
| SQLite + APCu | 1794,735 | 16,76 % |
| Docket | 1780,641 | 17,42 % |
| Redis | 2085,092 | 3,30 % |
Når det gælder kapacitet, ser vi en stigning på op til 23 %. Her er APCu den klare vinder, med Docket på andenpladsen med en forbedring på 21,6 %. Redis ramte ved siden af og gav kun en forbedring på 4,4 procent. Vi formoder, at Redis’ netværksoverhead giver de andre plugins en fordel.
De fleste implementeringer sænker også svartiden markant, og igen vinder APCu med 18,4 % kortere svartid. Docket er en tæt nummer to med 17,4 %, og SQLite + APCu tager tredjepladsen. Igen kommer Redis ind bagerst med kun 3,3 % kortere svartid.
Ud fra resultaterne står det klart, at der er en betydelig gevinst at hente ved at bruge en af disse cache-implementeringer. Du kan ikke bare håndtere flere forespørgsler pr. sekund, svartiden for forespørgslerne falder også markant.
Konklusion
Object caching er en mærkbar optimering. Alle de testede plugins gav mærkbare forbedringer af både kapacitet og svartid, men vinderen var ikke den, de fleste ville forvente.
APCu lå øverst på alle målinger med 23 % flere forespørgsler pr. sekund og 18 % kortere svartid ved 50 samtidige brugere. Docket Cache lå bemærkelsesværdigt tæt efter, og det er imponerende, når den udelukkende bruger filsystemet og OPcache uden eksterne afhængigheder. Det gør den til et godt valg på webhoteller, hvor APCu og Redis ikke er tilgængelige.
Redis, branchestandarden, gav kun 4,4 % flere forespørgsler pr. sekund.
Har din server APCu, så brug det. Er du på et webhotel, er Docket Cache et overraskende stærkt alternativ, der kun kræver PHP. Redis giver stadig mening, men du skal ikke være skuffet, hvis dit hostingmiljø ikke giver adgang til det. Der er mange gode alternativer, der kan holde din webshop kørende.