Det är lugnande text i en försäljningstratt, inte en teknisk garanti. När en värd trycker "obegränsat" på planens kort, lovar de inte oändlig överföring över fysik och budgetar; de lovar att inte mäta en specifik radpost på din faktura samtidigt som de kontrollerar allt annat som faktiskt avgör om din webbplats förblir snabb och tillgänglig. Den praktiska sanningen är enkel och lite irriterande: din plan kanske inte mäter månatlig överföring, men den kommer absolut att mäta dig på andra sätt så snart din användning ser ovanlig, spikig eller dyr att tjäna.
Jag har sett detta spelas ut tillräckligt många gånger för att kunna se mönstret från den första supporttråden. Webbplatsen börjar starkt, rankningar klättrar, en kampanj träffar, och sedan utvecklar "obegränsade" planen en personlighet. Förfrågningar tar längre tid. Statiska tillgångar kryper. Arbetare backar upp. Fel uppträder i fickor eftersom värden börjar skydda den delade miljön, inte din framgång. Det är inte illvilja; det är en ekonomisk verklighet. Värdar säljer "obegränsat" för att locka små webbplatser vars verkliga användning är liten och förutsägbar. Avvikelserna—video, nedladdningar, offentliga APIer, dåligt cachade appar—blir "missbruk" i samma ögonblick som graferna rör sig. ToS och resursschemaläggare träder in. Om du köpte "obegränsat" i förväntan att startbanan skulle skalas, kommer du att känna dig överrumplad. Om du behandlar det som omätbart på papper men mycket mätbart i praktiken, kommer du att fatta smartare arkitekturbeslut och undvika suspensionsmejlet som alltid anländer vid den minst bekväma tiden.
Bandbredd, överföring, genomströmning och porthastighet är inte samma sak
Jag bryr mig inte om hur många gånger branschen suddar ut termerna—om vi ska vara ärliga om vad du faktiskt kan skicka, måste vi separera vokabulären. Bandbredd är storleken på röret vid ett visst ögonblick. Genomströmning är vad du faktiskt uppnår genom det röret efter overhead, konkurrens och strypning. Dataöverföring är den totala mängden som flyttas över en viss period, vanligtvis en månad. Porthastighet är den hårda gränsen för omedelbart flöde, vanligtvis uttryckt som 10 Mbps, 100 Mbps, 1 Gbps eller högre.
"Omätad" är ett faktureringslöfte om månatlig överföring, inte om den omedelbara hastighet dina paket får vid middagstid på måndag. "Obegränsad" är en marknadsföringsflour som antyder att det inte finns något tak, men vad du egentligen har är en plan som inte räknar gigabyte för överskridande medan den genomdriver begränsningar genom allt annat: CPU-andelar, I/O, processantal, anslutningssamtidighet och slutligen den port dina paket måste passera. En 1 Gbps-port kan i teorin flytta en massiv mängd på en månad, men om värden formar din port till 100 Mbps efter fem minuter av konstant genomströmning—eller helt enkelt ger dig en "burstbar" körfält som minskar under belastning—försvinner din teoretiska överföring till verklig väntetid och misslyckade förfrågningar. Röret du trodde du köpte är röret du ockuperar endast när du är tyst.
När jag granskar en plan, frågar jag inte "Är bandbredd obegränsad?" Jag ställer en annan, fulare fråga: "Vilken är den värsta omedelbara genomströmningen jag är garanterad när grannarna och jag alla är upptagna?" Det är numret som håller din kassa från att stanna, dina bilder från att krypa och dina bakgrundsjobb från att bygga en landningsbana av omförsök du kommer att betala för senare.
Hur delad hosting är konstruerad för att se gränslös ut (tills den inte är det)
Delad hosting är en karnevalstrick byggt på genomsnitt. De flesta sajter är små. De flesta trafik är burstig på vänliga sätt. De flesta sidor är cachade efter den första genomsökningen. Det är så värdar kan överboka beräkningar, minne, lagring I/O och nätverksfiler medan de fortfarande erbjuder glada instrumentpaneler till tusentals kunder. Maskineriet bakom denna illusion är ett bo av rättvise-schemaläggare och kvotsystem. CPU-andelar förhindrar att ett enda konto tar en hel kärna under lång tid. IOPS-formning hindrar bullriga grannar från att svälta SAN. PHP-FPM och Node-processbegränsningar säkerställer att endast en handfull förfrågningar kan exekveras dynamiskt samtidigt. Inodetak begränsar tyst antalet filer du kan hålla på disk, vilket stryper mediatunga sajter innan överföringen någonsin dyker upp i en graf.
Det kritiska att notera är att inget av dessa system rör "bandbredd"-posten. Den förblir omätt, så påståendet förblir tekniskt ärligt. I samma ögonblick som din app börjar se upptagen ut mer än ett ögonblick, upprätthåller rättvise-reglerna "typisk användning" genom att strypa de delar av din stack de kontrollerar. Du kommer att se dynamiska förfrågningar köas medan statiska tillgångar känns bra. Sedan saktar statiska tillgångar ner eftersom ursprunget blir den flaskhals som en CDN inte fullt ut kan maskera. Värden debiterar dig fortfarande inte för överföring. De får dig helt enkelt att använda mindre av det genom att minska hur snabbt du kan leverera det.
Jag tror inte att delade värdar är skurkar för detta. Modellen fungerar för den stora majoriteten av webbplatser, och den har hållit webben billig för små utgivare. Men frasen "obegränsad bandbredd" ger fel mental modell. Den bjuder in dig att bygga som om du har en dedikerad fil, och det har du inte. Du har tillstånd att hälla vatten i en hink utan att betala per liter, men du delar fortfarande kranen.
Det finstilta som faktiskt styr din användning
Om du vill ha sanningen, läs inte prissättningsbordet; läs den Acceptabla Användningspolicyn. Du kommer att hitta sockerbelagda fraser som "typiska webbplatser" och "rättvis användning," vilket översätts till "om du börjar se ut som en filöverföringsnod, en strömningssajt, en mediespegel eller en nedladdningshub, förbehåller vi oss rätten att strypa, migrera eller stänga av dig." Du kommer att hitta förbud mot ljud- och videoströmning från ursprunget, filutdelning i stor skala, säkerhetskopieringsarkiv lagrade på webbplatsutrymme, offentligt tillgängliga ZIP-samlingar och "resursintensiva" skript som körs mer än några sekunder vardera. Du kommer att hitta dagliga CPU-sekundgränser, databasfråge-tak och anslutningsräkning som får din favorit asynkrona genomsökare att se ut som en attack.
Inträdesprocessbegränsningar är särskilt luriga. I cPanel-liknande miljöer betyder "en inträdesprocess" ofta "antalet samtidiga dynamiska förfrågningar som får starta." Nå det taket och nästa besökare köas inte; de får felmeddelanden. I/O-gränser och IOPS-nummer gör samma sak för disk. Inodetak avbryter dig när du har "för många filer," vilket ambitiösa mediebibliotek snubblar över innan de berör genomströmning. Inget av dessa saker bryter mot "obegränsad bandbredd." De säkerställer bara att du använder mycket lite av det när din sajt börjar växa.
Jag har tappat räkningen på de planer som hävdar "obegränsat" medan de tyst sätter CPU till "100% av en kärna under några sekunder," I/O till "några megabyte per sekund uthålligt," och processer till "en handfull åt gången." Det är ett bälte, hängslen och ett rep. Om du träffar alla tre, springer du inte; du släpar dig.
Hur "obegränsat" ser ut en hektisk måndag
Föreställ dig en vanlig måndag efter en helgomnämning som ger dig ny uppmärksamhet. Din HTML är rimligt lätt, dina bilder är hyfsade, du förlitar dig på en CDN för statiska tillgångar, och din ursprungshanterar de dynamiska delarna. Trafiken ökar fem gånger. Till en början är allt bra eftersom cacherna är varma och CDN:en hanterar de flesta bildförfrågningarna. Sedan hamnar dina dynamiska slutpunkter efter. Värdens processgräns håller bara ett litet antal samtidiga PHP- eller Node-arbetare aktiva. Köbildning börjar, och svarstiderna sträcks ut tillräckligt länge för att bryta timeout mellan tjänster. CDN:en hjälper fortfarande, men cache-missar på HTML börjar bita. Din databas blir mer pratig, och I/O-schemaläggaren drar bort en annan skiva eftersom du nu är "resursintensiv". Dina kunder, med perfekt timing, klickar på bilder som inte var heta i CDN, vilket drar utbrott från ursprung som kolliderar med långsamt dynamiskt arbete.
Vad som händer härnäst beror på värden. Vissa värdar stryper dig successivt tills prestandan är så dålig att besökare ger upp och ditt "genomsnitt" återgår till det normala. Andra utlöser automatiska missbruksregler och flyttar ditt konto till en lägre nivå pool eller en karantän-VLAN. Några kastar fortfarande det klassiska 509-svaret, "Bandbreddsgräns överskriden", även om de inte räknar bytes—509 är bara ett användbart stoppskylt för att köpa tid medan de granskar. Resultatet känns identiskt: löftet om "obegränsat" avdunstar precis när du behöver det.
En webbplats som huvudsakligen serverar cachelagrad HTML och statiska tillgångar kan kanske halta igenom med irriterade besökare. En butik med många varukorgar eller en app med mycket sökning kommer att ta det hårt. Smärtan visar sig sällan som ett snyggt, enkelt mått. Det är en mosaik av små förseningar som sammansätts till misslyckade köp och ökande övergivanden.
Innan vi går djupare, vill jag göra något konkret och återanvändbart så att du kan se det praktiska taket även när en plan hävdar att det inte existerar.
Jag ska gå in i hårda siffror i några minuter. Detta är en Premiumsektion fokuserad strikt på den matematik du kan göra på en servett för att översätta porthastighet till månatlig överföring och sedan till sidvisningar. Om du någonsin har kämpat för att kartlägga "1 Gbps omätad" till "Hur många besök kan jag faktiskt betjäna?" är detta där det knäpper i fokus.
Premium content
Logga in för att fortsätta
De tysta dödarna: CPU-strypning, IOPS-formning och processbegränsningar
Om du någonsin har känt att en webbplats saktar ner medan graferna såg "normala" ut, har du mött de tysta dödarna. CPU-strypning är mest synlig när du vet var du ska titta. Delade värdar tilldelar en del av en kärna för utbrott och sedan stryper de dig under varaktig belastning. Din app kraschar inte; den släpar. Det räcker för att slå ner sökrankningar och konverteringsgrader utan att utlösa larm som skulle få supporten involverad.
IOPS-formning är mer subtil. Databaser lever och dör av lagringslatens. Filintensiva appar gör det också. Värdar använder cgroups och lagrings-QoS för att hindra stora aktörer från att svälta ut arrayen. Du ser inte ett fel; du ser en tjugomillisekunders diskväntan förvandlas till åttio, vilket drar förfrågningstiderna in i en ny, fulare fördelning. Kombinera det med en låg inträdesprocessbegränsning och du har byggt en perfekt dragspel. Förfrågningar tar längre tid, så fler förfrågningar är samtidiga, vilket når begränsningen tidigare, vilket tappar nya besökare på golvet.
Processbegränsningar är slutligen giljotinen. Många planer begränsar PHP-FPM eller liknande till ett fåtal barn. Vissa lägger till en gräns för det totala antalet samtidiga processer per användare. Båda låter en värd le och lova "obegränsad bandbredd" samtidigt som de säkerställer att du inte i praktiken kan skicka särskilt mycket. Om du någonsin har jagat en spöklik flaskhals på CDN:en eller i din applikationskod bara för att upptäcka att värden tillåter åtta arbetare och kallar det en dag, har du känt fällan.
Jag sätter inte "obegränsad bandbredd" i min riskregister som ett problem att fixa. Jag minskar mitt beroende av det. Modellen som fungerar för de flesta små och medelstora webbplatser är tråkig och effektiv. Cachera HTML vid kanten så länge ditt innehåll tillåter. Skicka bilder, CSS och JS till ett CDN som du faktiskt validerar i produktion med en hög träffprocent, inte bara en logotyp. Offloada tung media till objektlagring och peka ditt CDN dit så att ursprunget aldrig ser det. Håll ursprunget fokuserat på dynamiska läsningar och skrivningar som verkligen behöver beräkning, och gör dem så statslösa och snabba som möjligt.
När du gör det, blir "obegränsad bandbredd"-planen acceptabel eftersom du inte ber den bära den belastning den inte kan bära utan drama. Även om värden formar ditt ursprung, absorberar CDN den slumpmässiga karaktären av trafiken. Din p95 stabiliseras, och du köper tid att välja en flytt när tillväxten är verklig istället för att reagera under ett avbrott. All finstilta finns fortfarande, men du trampar inte på den. Du har byggt ett litet, smidigt ursprung istället för ett lager.
Jag lägger aldrig videostreaming, filnedladdningar, offentliga mjukvaruspeglar eller backupdistribution på en plan som säger "obegränsad." Jag säger det som någon som har försökt pressa dem igenom och sedan förhandlat med ToS-språk efteråt. Dessa arbetsbelastningar är inte vad delad hosting är byggd för, och värden kommer att stänga ner dig i namn av att skydda alla andra. Även om du kommer undan med det kortvarigt, är du en nämnare bort från sidor av arga e-postmeddelanden och en migrering vid midnatt.
Tunga ZIP-arkiv av produktresurser eller utbildningsmaterial kommer att utlösa samma larm. Offentliga API:er som uppmuntrar klientpolling kommer också att göra det. Och allt som uppmuntrar användare att hämta samma flermegabytefil upprepade gånger på nya anslutningar kommer att träffa portformning snabbare än du tror. Den tråd som förbinder dessa fall är enkel: de är hög-utgående, låg-beräknings arbetsbelastningar som attackerar värdens transitnota utan att konsumera CPU eller I/O som deras schemaläggare är inställda på att mäta. Denna missanpassning är exakt varför "obegränsad bandbredd" existerar som frasering. Det är ett mjukt löfte byggt för att återkallas i samma ögonblick som din användning slutar se ut som en liten blogg.
Jag vill ge dig en advokat-med-benchmark översättningsguide du kan behålla. Nästa avsnitt är ett Premium Section där jag översätter de vanligaste klausulerna som värdar använder till operativ verklighet. Om du inte läser något annat, läs detta när du skannar en plan klockan 1 på morgonen och undrar om "obegränsat" kommer att bära din nästa lansering.
Premium content
Logga in för att fortsätta
Övervaka det som är viktigt så du vet innan avstängningsmailet kommer
Instrumentpanelen som din värd ger dig kommer inte att varna dig för det fel som är på väg. Den kommer att rapportera medelvärden och totaler medan smärtan gömmer sig i den långa svansen. Jag tittar på olika signaler. Ursprungsegress kontra CDN-egress berättar för mig om min cache gör sitt jobb. Om ursprungsegressen stiger snabbare än besök, vet jag att något kringgås eller rensas för aggressivt. Anslutningssamtidighet är kanariefågeln för processgränser; om samtidiga anslutningar närmar sig ett platt tak, förväntar jag mig omedelbara fel för nya besökare. 95:e percentilen för bandbredd och begäranstid är viktigare än medelvärden eftersom de förutser de delar av dagen där värden kommer att forma dig och dina användare kommer att misslyckas med att avsluta en resa.
CPU-stjälningstid är ett doftprov i delad miljö. Om jag ser att stjälandet ökar under mina tysta timmar, vet jag att jag tävlar med grannar och att min burst kommer att hamna på en trött nod. Långsamma frågor är alltid värda den tid du inte tror att du har; att fixa ett dåligt index kan vara skillnaden mellan att överleva en nämnande och att bränna en dag på att be om ursäkt. Felbudgetar—det antal fel du tillåter inom ett fönster innan du anser att användarupplevelsen är försämrad—knyter ihop allt detta. Om dina fel kryper upp innan trafiken gör det, har du osynlig friktion, och "obegränsat" kommer inte att dämpa något.
Följ pengarna och berättelsen slutar vara mystisk. Transit är dyrt om du inte kan förhandla fram bra peering och om dina användare sitter långt från dina POPs. Delad hosting amorterar den kostnaden över tusentals konton, varav de flesta knappt använder något. "Obegränsat" är ett verktyg för kundförvärv. Det minskar friktionen och jämförs väl på en tabell där den billigare planen "inkluderar" mer. Värden antar att du kommer att vara liten, eller att du kommer att göra det vettiga och flytta din tunga trafik till en CDN och objektlagring i samma ögonblick som du växer, vilket förskjuter egress till en leverantör som inte gör något annat än egress.
Moln inverterar modellen. De mäter egress eftersom det är deras vinstcentrum och eftersom deras nätverk är dyra att driva i global skala. De lovar inte "obegränsat" eftersom incitamentet är annorlunda; de vill att du ska arkitektera omtänksamt och betala för det du använder. Delade värdar vill att du ska ta med din lilla webbplats och förbli nöjd tills du inte längre är liten, vid vilket tillfälle de vill att du antingen optimerar eller uppgraderar. Inget av detta är cyniskt; det är så räkningarna betalas. Men det förklarar varför användarvillkoren är skrivna med sammetsord och varför de tekniska gränserna upprätthålls med lätt hand tills de inte gör det.
Beslutspunkter: när "obegränsat" är okej, när det är vårdslöst och hur man migrerar
Jag slänger inte "obegränsat" ut ur hand. För en liten marknadsföringswebbplats med mestadels statiska sidor och en blygsam blogg är det helt okej om du sätter en CDN framför den. För en butik med lätt trafik och rimlig caching kan det fungera medan du hittar produkt-marknadsanpassning. För en publikation som spikar oförutsägbart är det riskabelt om du inte aggressivt cachelagrar och förbereder. För allt som avger stora filer är det fel verktyg den dagen du lanserar.
Mitt beslutsträd är rakt på sak. Om din p95 dynamiska responstid är låg och förblir låg under lätt stress kan du köra på en delad plan längre än du tror. Om din CDN-träffprocent är genuint hög och din ursprungsegress förblir platt när trafiken fördubblas är du tillräckligt säker. Om någon av dessa förhållanden misslyckas, planera flytten nu. En liten VPS med två vCPU:er och tillräckligt med minne för att undvika swapping är tråkig och pålitlig. Det ger dig förutsägbar samtidighet, bättre lagringsprestanda och en nätverksbana du faktiskt kan förstå. Du kan fortfarande använda samma CDN- och objektlagringsstrategi. När du växer ur det kommer du att känna det på sätt du kan mäta och planera runt, och du kommer att kliva in i dedikerade eller hanterade kluster för att du väljer det, inte för att en ToS-klausul tvingade din hand.
Migrationsvägen behöver inte vara dramatisk. Håll ditt ursprung stateless där det är möjligt så DNS-övergångar blir rena. Lagra sessioner i en delad backend som du kan peka på från både gamla och nya ursprung under en kort överlappning. Värm upp cacheminnen innan du slår på strömbrytaren så att det nya ursprunget inte tar hela smällen. Poängen är inte att vara perfekt; det är att vara förutsägbar. "Obegränsat" sviker dig oförutsägbart. Ditt mål är att sluta bli överraskad.
Jag lovade praktiska, levda scenarier eftersom det är så gränserna för detta ämne blir uppenbara. Nästa avsnitt är en Premiumsektion med tre verkliga berättelser, var och en som börjar på "obegränsat," var och en som når en annan vägg och de exakta förändringarna som stabiliserade dem.
Premium content
Logga in för att fortsätta
Min hållning, rakt på sak: det är omätt, inte obegränsat — behandla det så
Jag har inget emot "obegränsad bandbredd" så länge vi är överens om att det betyder "vi kommer inte att räkna bytes" och inget mer. Det är omätt, inte oändligt. Kontrollerna som formar din upplevelse finns i CPU-delar, I/O-begränsningar, processgränser, samtidighetsgränser och kortlivade portformningar när du blir upptagen. Om du arkitekterar som en vuxen—CDN framför, avlastade tillgångar, minimerat och snabbt dynamiskt arbete—kan du leva lyckligt på en plan som marknadsför "obegränsat" eftersom du sällan behöver testa det. Om du arkitekterar som om du köpt en dedikerad fil, kommer du att lära dig betydelsen av "rättvis användning" första gången någon bryr sig om din sajt.
Så här jobbar jag. Jag behandlar ursprunget som ett litet API som förtjänar respekt. Jag flyttar tunga bytes till platser byggda för egress, och jag betalar för den egress för det är kostnaden för skala. Jag tittar på p95, inte genomsnitt. Jag håller ett öga på samtidighet och ett annat på den långa svansen av begärandetider. Jag läser användarvillkoren som om det är en teknisk dokumentation och översätter varje eufemism till en siffra. Jag accepterar att delat webbhotell är en övertecknad miljö med ett briljant värdeförslag för små sajter och en uppsättning hårda gränser för allt ambitiöst. När ambitionen kommer, flyttar jag för att jag vill, inte för att en sammetklausul säger till mig att jag måste.
Om du blivit bränd av "obegränsat", slå inte på dig själv. Formuleringen är avsedd att vara lugnande, och det fungerar. Bygg det lilla, motståndskraftiga ursprunget. Sätt en CDN framför. Avlasta de tunga sakerna. Känn dina siffror och dina flaskhalsar. När dagen kommer då du behöver en VPS eller något större, gör flytten med en varm cache och ett svalt huvud. Du kommer aldrig att se på "obegränsad bandbredd" på samma sätt igen, och det är poängen. Det var inte ett löfte. Det var en inbjudan att göra rätt arbete.
