Skip to content

Allt om WordPress, webbutveckling — och mer därtill

💡 Hur du minskar serverbelastningen och snabbar upp WordPress med Memcached

💡 Hur du minskar serverbelastningen och snabbar upp WordPress med Memcached

Ett WordPress-sajt utan cachning liknar en motor som värms upp från noll vid varje trafikljus. En besökare landar på en sida, PHP bygger ihop den från grunden och gör 30 till 60 anrop mot databasen. Tio samtidiga besökare innebär trehundra frågor. Femtio besökare skapar en lavin som får servern att tappa anslutningar snabbare än du hinner skriva klart ett kommando i konsolen.

Problemet är inte WordPress i sig. Dynamisk sidmontering är slösaktig som standard; nästan alla CMS fungerar på det här viset. Lösningen har bevisats genom många års drift på högt belastade projekt: objektcachning i RAM-minnet med Memcached. Ett korrekt konfigurerat Memcached-lager förvandlar en server som storknar vid femtio samtidiga användare till en maskin som hanterar hundratals utan en enda millisekunds tvekan i svarstiden.

Vi går igenom hela installationscykeln: från att installera daemonen till ett belastningstest som visar skillnaden i siffror. Alla kommandon har testats på Ubuntu 22.04/24.04 och AlmaLinux 9, och är kompatibla med PHP 8.2-8.5.

💡 Snabb översikt:

  • Installera Memcached-daemonen och bind den till localhost av säkerhetsskäl
  • Kompilera PHP-tillägget memcached via PECL för din PHP-version
  • Placera dropin-filen object-cache.php från Automattic i katalogen wp-content
  • Installera Batcache och konfigurera advanced-cache.php för sidcachning
  • Kontrollera svarshuvuden via webbläsarens DevTools
  • Kör ett belastningstest med k6 och jämför resultaten före och efter

Vad är Memcached och varför ditt WordPress behöver det

Memcached är en daemon som lagrar data och objekt i serverns RAM-minne. Till skillnad från filbaserad cachning (WP Super Cache, W3 Total Cache, WP Rocket), som skriver färdig HTML till disk, arbetar Memcached en nivå lägre: resultat från databasfrågor, sammansatta menyer, widgetar och webbplatsinställningar lägger sig i RAM-minnet och kan hämtas på mikrosekunder utan att behöva byggas om.

I praktiken ser bilden ut så här. En typisk WordPress-sida utan cachning gör 30 till 60 frågor mot MySQL. Med 50 samtidiga besökare får databasen mellan ett och ett halvt och tre tusen frågor, och processorn går in i felläge. Memcached fångar upp den överväldigande majoriteten av dessa frågor på RAM-nivå: databasen vilar, processorn förblir ledig och servern svarar omedelbart.

Tekniskt sett arbetar Memcached med nyckel-värde-par. Nyckeln är en hash av SQL-frågan; värdet är det serialiserade resultatet. När WordPress bygger ihop samma sida igen frågar det först Memcached: "Har du den här nyckeln?" och får nästan alltid ett färdigt svar utan en enda diskåtkomst.

Tekniken uppstod 2003 inom LiveJournal som en lösning på extrema databasbelastningsproblem. Idag körs WordPress.com, Wikipedia, Twitter och tusentals högt belastade projekt på Memcached. Det är moget, stabilt och förutsägbart: precis vad produktion behöver.

Installera Memcached-daemonen

Vi täcker två huvudscenarier: Ubuntu (22.04/24.04) med apt och AlmaLinux / Rocky Linux 9 med dnf. Anpassa kommandona till din distribution.

På Ubuntu:

1sudo apt update && sudo apt install memcached libmemcached-tools -y

På AlmaLinux / Rocky Linux 9:

1sudo dnf install memcached libmemcached -y

Efter installationen startar daemonen automatiskt. Kontrollera:

1systemctl status memcached

Som standard lyssnar Memcached på port 11211 på alla nätverksgränssnitt. Detta är ett säkerhetshål: din cache är tillgänglig för alla som kan nå den porten utifrån. Bind därför daemonen till localhost först.

Öppna konfigurationsfilen (/etc/memcached.conf på Ubuntu, /etc/sysconfig/memcached på AlmaLinux) och säkerställ att raden -l 127.0.0.1 finns och inte är bortkommenterad. Starta om daemonen:

1sudo systemctl restart memcached

Bygga PHP-tillägget via PECL

Enbart daemonen kommer inte att snabba upp WordPress; du behöver en PHP-klient som lär PHP att kommunicera med Memcached. Installera tillägget memcached (observera: specifikt memcached med bokstaven d, inte memcache). Det senare togs bort från PHP från och med version 8.0 och bör inte användas.

På Ubuntu installerar du först byggverktygen. Ersätt med din PHP-version: php8.4-dev, php8.3-dev eller php8.2-dev:

1sudo apt install php8.4-dev php-pear libmemcached-dev pkg-config make gcc -y

Bygg sedan tillägget:

1sudo pecl install memcached

På AlmaLinux / Rocky Linux 9 är uppsättningen liknande:

1sudo dnf install php-devel php-pear libmemcached-devel make gcc -y
2sudo pecl install memcached

Efter bygget måste tillägget registreras i PHP. Skapa en INI-fil:

1echo "extension=memcached.so" | sudo tee /etc/php/8.4/mods-available/memcached.ini
2sudo phpenmod memcached

På AlmaLinux blir sökvägen en annan: /etc/php.d/memcached.ini.

Om du arbetar i Plesk Obsidian är kommandot för att ladda om PHP-hanterare efter installation av tillägget:

1plesk bin php_handler --reread

Kontrollera att tillägget laddades:

1php -m | grep memcached

Utdata ska innehålla memcached. Om det är tomt, kontrollera sökvägen till INI-filen och starta om PHP-FPM: sudo systemctl restart php8.4-fpm.

Ansluta WordPress till Memcached

Daemonen är installerad; PHP-tillägget är laddat. Nu behöver du ansluta WordPress till Memcached på applikationsnivå.

De facto-standarden idag är den officiella drop-in-filen från Automattic: wp-memcached på GitHub. Den är skriven av samma utvecklare som underhåller Batcache och WordPress.com, och den fungerar korrekt med PHP 8.x (inklusive 8.4 och 8.5).

Kopiera filen object-cache.php från repositoriet till mappen /wp-content/ på din sajt. WordPress upptäcker den automatiskt och börjar använda Memcached som backend för objektcachen, utan ytterligare tillägg.

Om Memcached-porten avviker från standard (11211), lägg till följande i wp-config.php:

1$memcached_servers = array(
2 array( '127.0.0.1', 11211 )
3);

Sidcache: Batcache

Objektcache är halva jobbet. Den andra halvan är att cacha färdiga HTML-sidor så att PHP inte körs alls för anonyma besökare. Här kommer Batcache in, ett tillägg från Automattic som lagrar genererade sidor i samma Memcached.

Principen är enkel. En besökare kommer till sajten; Batcache kontrollerar om det finns en färdig HTML-kopia av denna sida i Memcached. Om det finns en och den inte har gått ut, serveras den direkt, förbi hela PHP- och MySQL-kedjan. Om inte, eller om besökaren är inloggad, genereras sidan på nytt och sparas samtidigt i cachen för efterföljande besök.

Installation:

Ladda ner arkivet från wordpress.org, packa upp det och ladda upp filen advanced-cache.php till roten av /wp-content/. Öppna sedan wp-config.php och lägg till raden som aktiverar cachelagring:

1define( 'WP_CACHE', true );

Skicka filen batcache.php till /wp-content/plugins/ och aktivera tillägget i adminpanelen.

Inuti advanced-cache.php finns ett drygt dussin inställningar under kommentarerna. De mest användbara: max_age (sidans livslängd i sekunder, standard 300 eller 5 minuter), seconds (intervall mellan regenereringar av samma URL) och unique (cacha inte olika User-Agents separat). För de flesta sajter fungerar standardvärdena; justera dem bara när du förstår varför.

En viktig detalj: se till att define( 'WP_CACHE', true ) står FÖRE raden require_once ABSPATH . 'wp-settings.php' i wp-config.php. Om den placeras efter kommer cachelagringen inte att aktiveras, och WordPress ignorerar det tyst.

Video: installation och konfiguration från början till slut

Teori är grunden, men konsolkommandon ser man bäst en gång. Den här videon täcker hela cykeln för att sätta upp objektcachelagring för WordPress med Redis och Memcached, från installation av daemonen till verifiering av resultatet:

Verifiera att Memcached fungerar

Det bästa testet är ett praktiskt sådant. Lägg till en anpassad header i advanced-cache.php så att du visuellt kan se om sidan serverades från cache eller genererades på nytt.

Hitta den här raden i advanced-cache.php:

1var $headers = array();

Ersätt den med:

1var $headers = array( 'memcached' => 'activated' );

Öppna nu DevTools i din webbläsare (F12), gå till fliken Nätverk och ladda om sidan flera gånger. Under Response Headers ser du ett fält memcached: activated, vilket betyder att Batcache fungerade och sidan gick till klienten direkt från RAM.

En ytterligare metod använder serverns kommandorad. Visa daemon-statistiken:

1echo "stats" | nc 127.0.0.1 11211

I utmatningen, leta efter get_hits och get_misses. Om get_hits växer när du uppdaterar sajtens sidor i webbläsaren, serverar Memcached cachade objekt på ett tillförlitligt sätt.

Lasttest: siffror, inte intryck

Memcached visar sitt verkliga värde under tryck. Det ursprungliga testet på en server med 1 kärna och 512 MB minne gav en imponerande kontrast: utan Memcached kraschade servern efter 15 sekunder med 50 samtidiga användare; med Memcached klarade den 400+ användare i 50 sekunder utan ett enda fel. Detta är inte magi utan fysik: när processorn inte lägger cykler på att sätta ihop samma sidor om och om igen, kan den betjäna nya besökare.

För självtestning idag används moderna verktyg. Ett av de smidigaste är k6 från Grafana (öppen källkod, körs med ett enda kommando). Ett grundläggande test:

1k6 run --vus 100 --duration 30s http://your-site.com/

100 virtuella användare i 30 sekunder. Jämför resultaten med Batcache inaktiverat (kommentera bort WP_CACHE) och aktiverat; skillnaden i lyckade svar och medianlatens kommer att mätas i storleksordningar.

För en snabb kontroll utan att installera programvara fungerar webbverktyget Loader.io bra; gratisnivån tillåter upp till 10 000 klienter per test, vilket är mer än tillräckligt för de flesta sajter.

Redis eller Memcached: vilken ska man välja

Frågan som oundvikligen dyker upp är varför inte Redis? Båda är nyckel-värde-lager i minnet; båda fungerar med WordPress via drop-ins. Det korta svaret: för ren cachning är Memcached enklare och snabbare; för allt annat, Redis.

Låt oss jämföra det väsentliga:

Kriterium

Memcached

Redis

Datamodell

Endast strängar

Strängar, listor, set, hash, geodata, pub/sub

Flertrådning

Använder alla kärnor direkt

Främst entrådig

Persistens

Ingen (rent i minnet)

RDB/AOF (sparar till disk)

WordPress-ekosystem

Automattic/wp-memcached + Batcache

Redis Object Cache (400 000+ installationer)

Installationskomplexitet

Minimal

Något högre

Cache-tömning vid omstart

Fullständig (men värms upp på minuter)

Kan bevaras

För cachning av WordPress-objekt är strängbaserad nyckel-värde mer än tillräckligt. De extra Redis-datatyperna behövs inte här. Vid get/set-operationer begränsas båda av nätverksgenomströmning snarare än CPU; allt annat lika är de jämbördiga. Memcached vinner på flertrådning: den använder alla CPU-kärnor direkt, medan Redis har en övervägande entrådig arkitektur.

Välj Redis om du också lagrar sessioner, uppgiftsköer eller behöver persistens. För uppgiften att "snabba upp WordPress och avlasta databasen" levererar Memcached resultat snabbare och med färre rörliga delar.

⁉️🤔 Vanliga frågor

Behöver jag Memcached på delat webbhotell?

På de flesta delade webbhotell är Memcached otillgängligt: leverantörer ger inte åtkomst till daemonen på servernivå. Men om ditt paket inkluderar en VPS eller dedikerad server tar installationen 10 till 15 minuter och ger en av de mest märkbara hastighetsvinsterna bland alla WordPress-optimeringar. Kontrollera ditt pakets möjligheter i kontrollpanelen eller fråga webbhotellets support.

Batcache eller WP Rocket: vilket är bättre?

WP Rocket är ett multiverktyg som hanterar sidcache (filbaserad), CSS/JS-optimering och lazy loading. Batcache är ett smalt verktyg specifikt för Memcached-baserad sidcache. De konkurrerar inte; de kompletterar varandra: Batcache arbetar på servernivå och serverar sidor utan att starta PHP, medan WP Rocket arbetar på applikationsnivå. I praktiken används ofta båda: Batcache för anonyma besökare, WP Rocket för finjusterad optimering.

Hur tömmer jag Memcached-cachen?

Den enklaste metoden är att starta om daemonen: sudo systemctl restart memcached. Cachen rensas helt och börjar värmas upp igen vid efterföljande besök. För riktad rensning, använd tillägget Query Monitor: det visar innehållet i objektcachen och tillåter tömning av enskilda nycklar. Det finns också ett konsolalternativ: echo "flush_all" | nc 127.0.0.1 11211.

Varför blev sajten inte snabbare efter installation av object-cache.php?

Den vanligaste orsaken är att PHP-tillägget inte laddades. Kontrollera php -m | grep memcached. Om utmatningen är tom, verifiera sökvägen till INI-filen och starta om PHP-FPM. Den näst vanligaste orsaken: object-cache.php kopierades inte till /wp-content/ eller kopierades med rättighetsfel (den måste vara läsbar för användaren som kör PHP). Tredje: Memcached-daemonen körs inte; kontrollera systemctl status memcached.

Konflikterar Memcached med OPcache?

Nej, det här är olika lager. OPcache cachar kompilerad PHP-bytekod och snabbar upp tolkens uppstart. Memcached cachar applikationsdata: resultat från databasfrågor. De arbetar i olika stadier av förfrågningshanteringen och kompletterar varandra väl. I produktion rekommenderas att använda båda.

Kan Memcached användas över flera servrar?

Ja, detta är ett av de primära scenarierna. I konfigurationen $memcached_servers kan du lista flera IP-adresser till Memcached-daemoner, och klienten kommer automatiskt att fördela nycklar mellan dem. För WordPress hanterar object-cache.php-drop-in detta: den stöder en serverpool direkt.

Bör du installera Memcached på din server

Att installera Memcached är inte en universallösning men ett av de mest effektiva stegen inom WordPress-optimering. Om din sajt körs på en VPS eller dedikerad server och du vill att den ska hantera mångdubbel trafiktillväxt utan att byta hårdvara, installera det. Tio till femton minuters konsoljobb, och databasen slutar vara en flaskhals.

Om sajten ligger på ett delat webbhotell utan åtkomst till daemonen, överväg Redis (erbjuds oftare) eller filbaserad cachning via WP Rocket. Om du redan finns på en VPS, öppna terminalen och följ stegen från den snabba översikten ovan. Du kommer att se resultatet i ditt första lasttest.