Varför WooCommerce kraschar på billigt webbhotell

Det börjar med en trafiktoppsdag som borde ha känts bra. Kampanjen fungerar, nyhetsbrevet nådde ut, folk klickar. Men istället för fler ordrar möts du av 508-fel och checkout-sidor som vägrar ladda. Du börjar inaktivera plugins i panik. Ingenting hjälper.

Problemet sitter inte i WordPress. Det sitter i servern under.

Varför just WooCommerce drabbas

På delat webbhotell delar du en fysisk server med hundratals andra kunder. Varje konto har en resurskvot för CPU, minne och antal processer. Det fungerar tillräckligt bra för en vanlig WordPress-sajt som kan cacha nästan allt som statisk HTML. En besökare som läser en cachad sida förbrukar i princip noll serverresurser.

WooCommerce kan inte fungera så. Varukorg, inloggningsstatus, lagerdata, betalningsflöden och rabattkoder är dynamiska av natur. Varje sidvisning kräver PHP-körning, databasanrop och sessionshantering. Tio samtidiga besökare i checkout belastar servern mer än hundra som läser cachade blogginlägg. Belastningen skalas direkt med trafiken, och resurskvoten på ett delat webbhotell är inte dimensionerad för det.

Till det kommer missförståndet om "obegränsat lagring", som är en marknadsföringsterm. Lagringsutrymme och beräkningsresurser är helt separata saker. Du kan ha terabyte lagring och fortfarande få 508-fel för att CPU-kapaciteten tar slut.

508 Resource Limit Reached

508 är inte ett WordPress-fel och inte ett PHP-fel. Det är webbhotellets infrastruktur som säger stopp. Det specifika resursmåttet som utlöser det är Entry Processes (EP), alltså antalet PHP-processer som får köras simultant för ditt konto.

Hur det händer i praktiken

Varje besökare som triggar PHP-kod skapar en process. Inte bara sidvisningar utan även AJAX-anrop, API-förfrågningar och formulärinlämningar. Typiska EP-gränser på delat webbhotell är 20 till 50 simultana processer.

Så här ser ett konkret scenario ut. Du skickar ett nyhetsbrev till 5 000 prenumeranter. Inom 60 sekunder klickar 200 av dem på länken till din butik. Varje klick skapar en PHP-process som tar 1 till 2 sekunder att exekvera. Du har plötsligt 50 till 100 processer som vill köra parallellt, men din EP-gräns är 30. Alla utöver de 30 första får ett 508-svar.

Det är inte ett extremt scenario. Det är en normal kampanjdag för en butik med en rimlig e-postlista.

Vad besökaren ser

Besökaren möts ofta av en sida med texten "Resource Limit Is Reached – The website is temporarily unable to service your request as it exceeded resource limit. Please try again later." I andra fall blir det en tom vit sida eller ett generiskt nätverksfel. Ingenting som förklarar vad som faktiskt gick fel. Kunden som just var redo att slutföra sitt köp ger upp och går vidare till en annan butik.

Varför det inte är ett plugin-problem

Den naturliga reflexen är att börja inaktivera plugins. Det är förståeligt men felaktigt. Ett plugin kan göra att varje process tar lite längre tid, vilket indirekt ökar risken för att nå EP-gränsen. Men inget plugin kan ta bort en hård infrastrukturgräns. Även med noll onödiga plugins har en WooCommerce-butik under trafikbelastning behov av fler simultana processer än vad 20 till 30 EP klarar av.

Det som skiljer 508 från andra fel är viktigt att förstå. Ett 500-fel är ett PHP-fel i din kod. Ett 503-fel betyder att servern är helt nere. 508 är specifikt resurstaket som nåtts. Servern kör. PHP fungerar. Det är bara fler besökare som vill in än vad din kvot tillåter.

PHP-minne och execution time

Om 508-felet är det akuta symptomet vid trafiktoppar, är PHP-konfigurationen det kroniska problemet som smyger sig på.

WooCommerce kräver minst 256 MB PHP-minne och rekommenderar 512 MB. max_execution_time behöver vara minst 300 sekunder. Det är de officiella kraven enligt WooCommerces serverdokumentation. Billigt delat webbhotell levererar ofta 128 till 256 MB minne och 30 sekunders execution time.

Gapet syns inte på prissidan. Det syns här:

• Minnesfel under checkout. I felloggen ser det ut så här: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 5242880 bytes). Siffran 134217728 är 128 MB uttryckt i bytes. Felet triggas särskilt med många produktvarianter i varukorgen eller under hög trafik.
• Produktimporter som avbryts halvvägs. Du importerar 500 produkter via CSV. PHP hinner med 200 innan felloggen skriver Fatal error: Maximum execution time of 30 seconds exceeded och processen dödas. Resterande 300 saknas, men i WordPress-admin ser du bara en spinner som slutar snurra.
• Backup-plugins som tyst slutar fungera. Samma timeout-fel, men du ser det inte förrän du faktiskt behöver återställa och upptäcker att senaste lyckade backupen var för tre veckor sedan.
• PDF-fakturagenerering som misslyckas. Plugin som genererar fakturor eller fraktsedlar behöver ofta mer tid och minne än vad budgetplaner ger.

Sedan WordPress 5.2 döljs dessa fel bakom ett generiskt meddelande: "There has been a critical error on this website." Det är det enda besökaren ser. Den faktiska orsaken finns i felloggen och i det e-postmeddelande WordPress skickar till administratörens adress med ämnesraden "Your Site is Experiencing a Technical Issue".

Att du inte ser fel nu betyder inte att minnet räcker. PHP kan döda processer tyst utan att skriva till felloggen. Det kan betyda att du inte har testat under rätt förhållanden. Kontrollera din faktiska konfiguration under WooCommerce, Status, System Status. Där ser du vad PHP rapporterar och om WooCommerce flaggar något som otillräckligt.

Om du vill ha en samlad bild av vilka tekniska krav du bör ställa på ditt webbhotell beroende på din butiks storlek, finns det genomgånget i detalj.

Databasen: anslutningsgränser, I/O och den cache som saknas

WooCommerce är ovanligt databasintensivt. En enkel produktsida kan generera 20 till 50 separata databasanrop. En checkout-sida fler. Med 50 samtida besökare multipliceras det snabbt till tusentals förfrågningar per sekund.

MySQL-anslutningsgränser

Delat webbhotell begränsar antalet simultana MySQL-anslutningar per konto, ofta till 15 till 30. I PHP-loggen syns felet som mysqli_real_connect(): (HY000/1040): Too many connections. Besökaren ser WordPress standardsida med texten "Error establishing a database connection". Sajten ser ut att vara helt nere, men det är den inte. Databasservern kör, men köen är full och nya anslutningar avvisas.

Disk I/O

Delat webbhotell tillåter typiskt 1 till 5 MB per sekund i diskgenomströmning. En NVMe-SSD på en VPS levererar 1 000+ MB/s. Under belastning köas diskoperationer. En databassökning som normalt tar 10 millisekunder tar plötsligt 2 sekunder. Sidan laddar på 10 till 15 sekunder. Servern är inte nere. Den väntar bara på disk.

Från utsidan ser det bara ut som en seg sajt, vilket gör att butiksägare letar lösningar i teman och plugins när problemet sitter i hårdvaran.

Varför ditt caching-plugin inte löser det

Det finns en viktig distinktion som ofta hoppas över. Sidcache sparar färdig HTML och levererar den utan att köra PHP. Det fungerar bra för statiska sidor, men WooCommerce-sidor med varukorg, inloggade kunder och realtidslagerstatus kan inte cachas fullt ut. Checkout-sidor cachas aldrig. Ungefär hälften av butiksflödet är undantaget från sidcache av nödvändighet.

Objektcache löser det andra problemet. Det sparar resultaten av databasförfrågningar i RAM, så nästa förfrågan hämtar svaret från minnet istället för att köra frågan mot databasen igen. Redis är den vanligaste tekniken för det.

Här kommer missförståndet. Du kan installera ett Redis-objektcache-plugin i WordPress, men pluginet gör ingenting om det inte finns en Redis-server på hostinginfrastrukturen. Pluginet är en klient. Utan server att ansluta till är det en tom skal. Samma sak med LiteSpeed Cache. Det är ett utmärkt plugin för sidcache, men det ersätter inte Redis och ger inte objektcache i den bemärkelsen.

De flesta budgetpaket saknar Redis. Det finns på dyrare planer och hos leverantörer som riktar sig mot WordPress och WooCommerce specifikt. Om du letar efter webbhotell med Redis och servernivå-caching kan du jämföra de alternativ som faktiskt erbjuder det.

Andra gränser som sällan syns på prissidan

Cron-jobb

WooCommerce använder schemalagda bakgrundsprocesser för orderbekräftelser, lagersynkronisering och kampanjrabatter. Billigt delat webbhotell tillåter cron-jobb med ett minimum av 5 till 15 minuters intervall. Ett kampanjpris som ska starta kl 00:00 kanske aktiveras 00:14. Värre är att cron-jobb som kräver mer resurser än tillåtet avbryts halvvägs och kan lämna databasen i inkonsekvent tillstånd.

WooCommerce använder Action Scheduler för att hantera bakgrundsuppgifter. När schemalagda jobb inte hinner köras i tid visas en gul varning i WordPress-admin: "Action Scheduler: X past-due actions found; something may be wrong." Det är en tydlig signal att hostingmiljön inte klarar belastningen.

Dessutom använder WordPress inte riktig systemcron utan WP-Cron, som triggas av besökartrafik. Om butiken har låg trafik en natt körs det schemalagda jobbet helt enkelt inte förrän någon besöker sajten.

Inode-gränsen

Varje fil och katalog tar en inode i filsystemet. Delat webbhotell sätter typiskt en gräns på 150 000 till 250 000 inodes per konto. En WooCommerce-butik konsumerar dem snabbare än man tror:

• 500 produkter med bilder i flera storlekar: ~25 000 inodes
• Caching-plugin med filcache: 50 000+ inodes
• E-postkonton med historik: upp till 100 000 inodes

Symptomen är förvirrande. I felloggen står det No space left on device (28) trots att du har gigabyte lagringsutrymme kvar. I WordPress-admin möts du av "Upload: Failed to write file to disk" vid bilduppladdning eller "Unable to create directory wp-content/uploads" vid plugin-uppdateringar. Lagringsutrymme och inode-kvot är separata begränsningar, och felmeddelandena förklarar inte vilken av dem som är uppnådd.

Så tar du reda på om webbhotellet är problemet

Innan du börjar felsöka plugins och teman, samla in fakta om infrastrukturen. Här är en konkret checklista.

Kontrollera din PHP-konfiguration

Gå till WooCommerce, Status, System Status i WordPress-admin. Du ser där memory_limit, max_execution_time och om WooCommerce flaggar något som otillräckligt. Om memory_limit är under 256 MB eller max_execution_time under 120 sekunder har du ett konkret kravgap.

Kontrollera din EP-användning

Har du cPanel-åtkomst hittar du ofta Entry Processes i resursöversikten. Ligger den regelbundet nära taket under normal drift är det ett tydligt varningssignal.

Korrelera felen med tidpunkter

Det här är ett av de starkaste felsökningsverktygen du har. Kodfel är konsistenta, de inträffar oavsett trafik. Infrastrukturproblem är trafikkänsliga. Om felen kommer vid kampanjer, nyhetsbrevskick eller högtrafik-timmar vet du var problemet sitter.

Ställ tre frågor till supporten

1. Vad är min memory_limit och kan den höjas?
2. Vad är min EP-gräns?
3. Erbjuder ni Redis för objektcache?

Svaren berättar mer om hostingens lämplighet för WooCommerce än hela prissidan. Gör det här innan du inaktiverar ett enda plugin.

Vad du kan göra, och vad som kräver byte

Några saker kan du faktiskt åtgärda utan att byta webbhotell:

• Begär höjd memory_limit. Många webbhotell kan justera det per konto utan att du behöver uppgradera. Fråga explicit.
• Rensa cache-filer regelbundet. Ett caching-plugin som byggt upp 80 000 filer äter aktivt in på din inode-kvot.
• Schemalägg nyhetsbrev till lågtrafik. Tidiga morgnar eller sena kvällar, inte mitt under en kampanj.
• Avaktivera objektcache-plugin om Redis saknas. Det gör ingenting nyttigt utan Redis-server och kan faktiskt förvärra situationen.

Annat kan inte lösas inom ett budgetpaket. EP-gränsen är en hård infrastrukturgräns som inte kan förhandlas upp. Redis kräver en annan hostingtyp. max_execution_time över 60 sekunder är ofta en gräns som supporten inte kan ändra per konto.

Om din butik kräver mer än vad infrastrukturen kan leverera finns det i grunden två vägar vidare. Artikeln om det är dags att uppgradera till VPS går igenom de konkreta tecknen på att du har vuxit ur delat webbhotell. Managed WordPress-hosting är alternativet för dig som vill ha dedikerade resurser och inbyggd Redis utan att hantera en server manuellt. Om du vill optimera det du kan inom WordPress-miljön har vi en guide om hur du optimerar WordPress för bättre laddtid.

En butik som växer och kör kampanjer behöver en hosting som klarar trafikpikar med marginal. Det kravet levererar inte ett paket med 20 Entry Processes och 128 MB minne, oavsett hur bra prissidan ser ut. Om du är redo att jämföra alternativ som faktiskt är byggda för den belastningen är webbhotell optimerade för WooCommerce en bra startpunkt.