Det er beroligende tekst i en salgstrakt, ikke en teknisk garanti. Når en vert skriver "ubegrenset" på plan kortet, lover de ikke uendelig overførsel på tvers av fysikk og budsjetter; de lover å ikke måle ett spesifikt linjepunkt på din faktura mens de kontrollerer alt annet som faktisk styrer om nettstedet ditt forblir raskt og tilgjengelig. Den praktiske sannheten er enkel og litt irriterende: planen din måler kanskje ikke månedlig overførsel, men den vil absolutt måle deg på andre måter i det øyeblikket bruken din ser uvanlig, spisset eller dyr ut å betjene.
Jeg har sett dette spille ut nok ganger til å se mønsteret fra den første støttetråden. Nettstedet starter sterkt, rangeringene klatrer, en kampanje treffer, og så utvikler "ubegrenset" planen en personlighet. Forespørsler tar lengre tid. Statisk innhold kryper. Arbeidere hoper seg opp. Feil oppstår i lommer fordi verten begynner å beskytte det delte miljøet, ikke din suksess. Det er ikke ondskap; det er en økonomisk realitet. Vertene selger "ubegrenset" for å tiltrekke seg små nettsteder hvis reelle bruk er liten og forutsigbar. Utløperne—video, nedlastinger, offentlige APIer, dårlig hurtigbufrede apper—blir "misbruk" i det øyeblikket grafene beveger seg. Vilkårene og ressursplanleggerne trer i kraft. Hvis du kjøpte "ubegrenset" i forventning om å skalere, vil du føle deg blindsidet. Hvis du behandler det som umålt på papiret men veldig målt i praksis, vil du ta smartere arkitekturavgjørelser og unngå suspensjons-e-posten som alltid kommer på det minst praktiske tidspunktet.
Båndbredde, overføring, gjennomstrømning og porthastighet er ikke det samme
Jeg bryr meg ikke om hvor mange ganger bransjen blander begrepene—hvis vi skal være ærlige om hva du faktisk kan presse, må vi skille vokabularet. Båndbredde er størrelsen på røret i et øyeblikk. Gjennomstrømning er hva du faktisk oppnår gjennom det røret etter overhead, konkurranse og struping. Dataoverføring er den totale mengden flyttet over en periode, vanligvis en måned. Porthastighet er den harde grensen for øyeblikkelig flyt, vanligvis uttrykt som 10 Mbps, 100 Mbps, 1 Gbps eller høyere.
"Ubegrenset" er et faktureringsløfte om månedlig overføring, ikke om den øyeblikkelige hastigheten pakkene dine får kl. 12 på mandag. "Ubegrenset" er en markedsføringsflourish som antyder at det ikke er noen grense, men det du egentlig har, er en plan som ikke teller gigabyte for overtredelse samtidig som den håndhever begrensninger gjennom alt annet: CPU-andeler, I/O, prosessantall, tilkoblingssamtidig, og til slutt porten pakkene dine må krysse. En 1 Gbps port kan i teorien flytte en massiv mengde i løpet av en måned, men hvis verten former porten din til 100 Mbps etter fem minutter med vedvarende gjennomstrømning—eller rett og slett gir deg en "utbruddsvennlig" kjørefelt som reduseres under belastning—fordamper din teoretiske overføring til reell ventetid og mislykkede forespørsler. Røret du trodde du kjøpte, er røret du okkuperer bare når du er stille.
Når jeg vurderer en plan, spør jeg ikke "Er båndbredden ubegrenset?" Jeg stiller et annet, styggere spørsmål: "Hva er den verste øyeblikkelige gjennomstrømningen jeg er garantert når naboene og jeg alle er opptatt?" Det er tallet som hindrer utsjekkingen din fra å stoppe opp, bildene dine fra å krype, og bakgrunnsjobbene dine fra å bygge en rullebane av gjentakelser du vil betale for senere.
Hvordan delt hosting er konstruert for å virke grenseløs (inntil den ikke er det)
Delt hosting er et karnevaltriks bygget på gjennomsnitt. De fleste nettsteder er små. De fleste trafikk er sprudlende på vennlige måter. De fleste sider er bufret etter første gjennomgang. Slik kan verter overbooke prosessorkraft, minne, lagring I/O og nettverksbaner mens de fortsatt leverer glade dashbord til tusenvis av kunder. Maskineriet bak denne illusjonen er et rede av rettferdighetsplanleggere og kvotesystemer. CPU-aksjer forhindrer en enkelt konto fra å ta en full kjerne for lenge. IOPS-forming hindrer støyende naboer fra å sulte SAN. PHP-FPM og Node prosessgrenser sikrer at bare en håndfull forespørsler kan utføres dynamisk om gangen. Inode-grenser begrenser stille antall filer du kan holde på disk, og kveler mediatunge nettsteder før overføringen noen gang vises på en graf.
Det kritiske å legge merke til er at ingen av disse systemene berører “båndbredde”-linjepunktet. Det forblir umålt, så påstanden forblir teknisk ærlig. I det øyeblikket appen din begynner å se opptatt ut i mer enn et øyeblikk, håndhever rettferdighetsreglene “typisk bruk” ved å strupe delene av stabelen din de kontrollerer. Du vil se dynamiske forespørsler kø mens statiske ressurser føles greit. Deretter vil statiske ressurser sakte fordi opprinnelsen blir flaskehalsen som et CDN ikke fullt ut kan maskere. Verten belaster deg fortsatt ikke for overføring. De bare sørger for at du bruker mindre av det ved å redusere hvor raskt du kan levere det.
Jeg tror ikke delte verter er skurker for dette. Modellen fungerer for det store flertallet av nettsteder, og den har holdt weben rimelig for små utgivere. Men uttrykket “ubegrenset båndbredde” gir feil mental modell. Det inviterer deg til å konstruere som om du har en dedikert bane, og det har du ikke. Du har tillatelse til å helle vann i en bøtte uten å betale per liter, men du deler fortsatt kranen.
Det med liten skrift som faktisk styrer bruken din
Hvis du vil ha sannheten, ikke les pristabellen; les retningslinjene for akseptabel bruk. Du vil finne sukkerbelagte setninger som “typiske nettsteder” og “rettferdig bruk,” som oversettes til “hvis du begynner å se ut som en filutvekslingsnode, et streamingnettsted, et mediespeil eller et nedlastingsknutepunkt, forbeholder vi oss retten til å strupe, migrere eller suspendere deg.” Du vil finne forbud mot lyd- og videostrømming fra opprinnelsen, filfordeling i stor skala, sikkerhetskopiarkiver lagret på webområdet, offentlig tilgjengelige ZIP-samlinger, og “ressursintensive” skript som kjører i mer enn noen få sekunder hver. Du vil finne daglige CPU-sekundgrenser, databasforespørselsgrenser og tilkoblingstelling som får din favoritt asynkrone crawler til å se ut som et angrep.
Inngangsprosessgrenser er spesielt lumske. I cPanel-lignende miljøer betyr en “inngangsprosess” ofte “antall samtidige dynamiske forespørsler som får starte.” Treffer du den grensen, står den neste besøkende ikke i kø; de får feil. I/O-grenser og IOPS-tall gjør det samme med disk. Inode-grenser kutter deg av når du har “for mange filer,” som ambisiøse mediebiblioteker utløser før de berører gjennomstrømning. Ingen av disse tingene bryter “ubegrenset båndbredde.” De sikrer bare at du bruker svært lite av det når nettstedet ditt begynner å vokse.
Jeg har mistet tellingen på planene som hevder å være “ubegrenset” mens de stille setter CPU til “100% av en kjerne i noen få sekunder,” I/O til “noen megabyte per sekund vedvarende,” og prosesser til “en håndfull om gangen.” Det er et belte, seler, og et tau. Hvis du treffer alle tre, løper du ikke; du rusler.
Hvordan "ubegrenset" ser ut på en travel mandag
Tenk deg en vanlig mandag etter at en omtale i helgen gir deg ny oppmerksomhet. HTML-en din er rimelig lett, bildene dine er greie, du stoler på en CDN for statiske ressurser, og opprinnelsen din håndterer de dynamiske bitene. Trafikken øker med en faktor på fem. I begynnelsen er alt fint fordi cachene er varme og CDN-en spiser de fleste bildespørsmålene. Så faller de dynamiske endepunktene dine bakpå. Vertens prosessgrense holder bare et lite antall samtidige PHP- eller Node-arbeidere aktive. Køen begynner, og responstidene strekker seg lenge nok til å bryte tidsavbrudd mellom tjenester. CDN-en hjelper fortsatt, men cache-missene på HTML begynner å merkes. Databasen din blir mer pratsom, og I/O-planleggeren trekker fra en annen bit fordi du nå er "ressursintensiv." Kundene dine, med perfekt timing, klikker på bilder som ikke var varme i CDN-en, og trekker utbrudd fra opprinnelsen som kolliderer med treg dynamisk arbeid.
Hva som skjer videre avhenger av verten. Noen verter struper deg gradvis til ytelsen er så dårlig at besøkende gir opp og din "gjennomsnittlige" går tilbake til det normale. Andre utløser automatiserte misbruksregler og flytter kontoen din til en lavere nivå pool eller en karantene-VLAN. Noen få kaster fortsatt den klassiske 509-responsen, "Båndbreddegrense overskredet," selv om de ikke teller bytes—509 er bare et nyttig stopptegn for å kjøpe tid mens de vurderer. Resultatet føles identisk: løftet om "ubegrenset" fordamper akkurat når du trenger det.
Et nettsted som serverer mest cachet HTML og statiske ressurser kan kanskje halte gjennom med irriterte besøkende. En handlekurvtung butikk eller en søketung app vil ta det på haken. Smerten vises sjelden som en ryddig, enkeltmetrisk. Det er en mosaikk av små forsinkelser som bygger seg opp til mislykkede utsjekkinger og økende forlatelse.
Før vi går dypere, vil jeg gjøre noe konkret og gjenbrukbart slik at du kan se det praktiske taket selv når en plan hevder at det ikke eksisterer.
Jeg kommer til å gå inn i harde tall i noen minutter. Dette er en Premium-seksjon fokusert direkte på matematikken du kan gjøre på en serviett for å oversette porthastighet til månedlig overføring og deretter til sidevisninger. Hvis du noen gang har slitt med å kartlegge "1 Gbps umålt" til "Hvor mange besøk kan jeg faktisk betjene?" er dette hvor det blir klart.
Premium content
Logg inn for å fortsette
De stille drapsmennene: CPU-throttling, IOPS-forming og prosessgrenser
Hvis du noen gang har følt at et nettsted bremser opp mens grafer så "normale" ut, har du møtt de stille drapsmennene. CPU-throttling er den mest synlige når du vet hvor du skal se. Delte vertsmaskiner tildeler en del av en kjerne for utbrudd og reduserer deretter under vedvarende belastning. Appen din krasjer ikke; den drar. Det er nok til å senke søkerangeringer og konverteringsrater uten å utløse alarmer som ville fått støtte involvert.
IOPS-forming er mer subtil. Databaser lever og dør av lagringslatens. Filtunge apper gjør det også. Vertsmaskiner bruker cgroups og lagrings-QoS for å hindre store aktører i å sulte ut matrisen. Du ser ikke en feil; du ser en tjue millisekunders diskventetid bli til åtti, noe som trekker forespørselstider inn i en ny, styggere fordeling. Par det med en lav inngangsprosessgrense, og du har bygget en perfekt squeezeboks. Forespørsler tar lengre tid, så flere forespørsler er samtidige, noe som treffer grensen raskere, som slipper nye besøkende på gulvet.
Prosessgrenser er til slutt giljotinen. Mange planer begrenser PHP-FPM eller lignende til en håndfull barn. Noen legger til en grense på totalt samtidige prosesser per bruker. Begge lar en vertsmaskin smile og love "ubegrenset båndbredde" mens de sørger for at du ikke, i praksis, kan sende veldig mye. Hvis du noen gang har jaget en fantomflaskehals på CDN-en eller i applikasjonskoden din bare for å oppdage at verten tillater åtte arbeidere og kaller det en dag, har du følt fellen.
Jeg setter ikke "ubegrenset båndbredde" i risikoregisteret mitt som et problem å fikse. Jeg reduserer min avhengighet av det. Modellen som fungerer for de fleste små og mellomstore nettsteder er kjedelig og effektiv. Cache HTML på kanten så lenge innholdet ditt tillater det. Skyv bilder, CSS og JS til en CDN som du faktisk validerer i produksjonen med høy treffrate, ikke bare en logo. Last av tung media til objektlagring og pek CDN-en din der, slik at opprinnelsen aldri ser den. Hold opprinnelsen fokusert på dynamiske lesninger og skrivinger som virkelig trenger beregning, og gjør dem så statsløse og raske som mulig.
Når du gjør det, blir "ubegrenset båndbredde"-planen akseptabel fordi du ikke ber den bære lasten den ikke kan bære uten drama. Selv om verten former opprinnelsen din, absorberer CDN-en trafikkens tilfeldige natur. Din p95 stabiliserer seg, og du kjøper tid til å velge et trekk når veksten er reell i stedet for å reagere under et avbrudd. All den fine skriften eksisterer fortsatt, men du tråkker ikke på den. Du har bygget en liten, smidig opprinnelse i stedet for et lager.
Jeg setter aldri videostrømming, fildownloads, offentlige programvarespeil eller backupdistribusjon på en plan som sier "ubegrenset." Jeg sier det som noen som har prøvd å presse dem gjennom og deretter forhandlet med ToS-språk etter faktum. Disse arbeidsmengdene er ikke det delte hosting er bygget for, og verten vil stenge deg ned i navnet på å beskytte alle andre. Selv om du slipper unna med det kortvarig, er du en omtale unna sider med sinte e-poster og en migrasjon ved midnatt.
Tunge ZIP-arkiver av produktressurser eller læringsmateriale vil utløse de samme alarmene. Offentlige API-er som oppmuntrer til klientpolling vil også gjøre det. Og alt som oppmuntrer brukere til å hente den samme multimålsfilen gjentatte ganger på nye tilkoblinger vil treffe portforming raskere enn du tror. Tråden som forbinder disse tilfellene er enkel: de er høyt-utgang, lav-beregning arbeidsmengder som angriper vertens transittregning uten å konsumere CPU eller I/O som deres planleggere er innstilt på å måle. Den misforholdet er akkurat hvorfor "ubegrenset båndbredde" eksisterer som en formulering. Det er et mykt løfte bygget for å bli tilbakekalt i det øyeblikket bruken din slutter å se ut som en liten blogg.
Jeg vil gi deg en advokat-med-benchmarks oversettelsesguide du kan beholde. Neste seksjon er en Premium-seksjon der jeg oversetter de vanligste klausulene vertsmaskiner bruker til operasjonell virkelighet. Hvis du ikke leser noe annet, les dette når du skanner en plan klokken 1 om natten og lurer på om "ubegrenset" vil bære din neste lansering.
Premium content
Logg inn for å fortsette
Overvåking av det som betyr noe, slik at du vet før suspensjons-e-posten kommer
Dashbordet verten din gir deg, vil ikke advare deg om feilen som kommer. Det vil rapportere gjennomsnitt og totaler mens smerten skjuler seg i den lange halen. Jeg ser på forskjellige signaler. Opprinnelsens utgående trafikk versus CDN-utgående trafikk forteller meg om hurtigbufferen min gjør jobben sin. Hvis opprinnelsens utgående trafikk øker raskere enn besøkene, vet jeg at noe blir omgått eller tømt for aggressivt. Tilkoblingssamtidighet er kanarifuglen for prosessgrenser; hvis samtidige tilkoblinger nærmer seg et flatt tak, forventer jeg umiddelbare feil for nye besøkende. Båndbredde og forespørselstid for 95. persentil betyr mer enn gjennomsnitt, fordi de forutsier delene av dagen hvor verten vil forme deg, og brukerne dine vil mislykkes i å fullføre en reise.
CPU-stjåletid er en luktetest for delt miljø. Hvis jeg ser stjåletid øke i mine stille timer, vet jeg at jeg konkurrerer med naboer og at utbruddet mitt vil lande på en sliten node. Sakte forespørsler er alltid verdt tiden du ikke tror du har; å fikse et dårlig indeks kan være forskjellen mellom å overleve en omtale og å bruke en dag på å be om unnskyldning. Feilbudsjetter—antallet feil du tillater i et vindu før du anser brukeropplevelsen som degradert—binder alt dette sammen. Hvis feilene dine kryper opp før trafikken gjør det, har du usynlig friksjon, og "ubegrenset" vil ikke dempe noe.
Følg pengene og historien slutter å være mystisk. Transit er dyrt hvis du ikke kan forhandle frem gode peering-avtaler, og hvis brukerne dine sitter langt fra dine POP-er. Delt hosting amortiserer den kostnaden over tusenvis av kontoer, de fleste av dem knapt bruker noe. "Ubegrenset" er et verktøy for kundeanskaffelse. Det senker friksjonen og sammenligner godt på en tabell hvor den billigere planen "inkluderer" mer. Verten antar at du vil være liten, eller at du vil gjøre det fornuftige og flytte din tunge trafikk til en CDN og objektlagring når du vokser, noe som flytter utgående trafikk til en leverandør som ikke gjør annet enn utgående trafikk.
Skyer inverterer modellen. De måler utgående trafikk fordi det er deres fortjenestesenter og fordi nettverkene deres er kostbare å drive i global skala. De lover ikke "ubegrenset" fordi insentivet er annerledes; de vil at du skal arkitektere gjennomtenkt og betale for det du bruker. Delt verter vil at du skal ta med ditt lille nettsted og forbli fornøyd til du ikke er liten, hvorpå de vil at du enten skal optimalisere eller oppgradere. Ingenting av dette er kynisk; det er slik regningene blir betalt. Men det forklarer hvorfor bruksvilkårene er skrevet i fløyelsspråk og hvorfor de tekniske grensene håndheves med en lett berøring inntil de ikke gjør det.
Beslutningspunkter: når "ubegrenset" er greit, når det er uforsvarlig, og hvordan migrere
Jeg kaster ikke "ubegrenset" ut av hånden. For et lite markedsføringsnettsted med for det meste statiske sider og en beskjeden blogg, er det helt greit hvis du setter en CDN foran det. For en butikk med lett trafikk og fornuftig caching, kan det fungere mens du finner produkt-marked-tilpasning. For en publikasjon som topper uforutsigbart, er det risikabelt med mindre du aggressivt cacher og forhåndsrendrer. For alt som sender ut store filer, er det feil verktøy den dagen du lanserer.
Mitt beslutningstre er enkelt. Hvis din p95 dynamiske responstid er lav og holder seg lav under lett stress, kan du bruke en delt plan lenger enn du tror. Hvis din CDN-treffrate er genuint høy og din opprinnelsegress holder seg flat når trafikken dobles, er du trygg nok. Hvis noen av disse betingelsene svikter, planlegg flyttingen nå. En liten VPS med to vCPUs og nok minne til å unngå swapping er kjedelig og pålitelig. Det gir deg forutsigbar samtidighet, bedre lagringsytelse og en nettverkslinje du faktisk kan forstå. Du kan fortsatt bruke den samme CDN- og objektlagringsstrategien. Når du vokser ut av det, vil du merke det på måter du kan instrumentere og planlegge rundt, og du vil gå over til dedikerte eller administrerte klynger fordi du velger å, ikke fordi en vilkårsklausul tvang deg.
Migreringsveien trenger ikke være dramatisk. Hold opprinnelsen stateless der det er mulig slik at DNS-kuttene er rene. Lagre økter i en delt backend du kan peke på fra både gamle og nye opprinnelser under en kort overlapping. Varm opp cacher før du slår om bryteren slik at den nye opprinnelsen ikke tar hele belastningen. Poenget er ikke å være perfekt; det er å være forutsigbar. "Ubegrenset" svikter deg uforutsigbart. Målet ditt er å slutte å bli overrasket.
Jeg lovet praktiske, levde scenarier fordi det er slik kantene av dette emnet blir åpenbare. Neste seksjon er en Premium-seksjon med tre virkelige historier, hver som starter på "ubegrenset," hver som treffer en annen vegg, og de nøyaktige endringene som stabiliserte dem.
Premium content
Logg inn for å fortsette
Mitt standpunkt, rett på sak: det er umålt, ikke ubegrenset — behandle det slik
Jeg har ikke noe imot "ubegrenset båndbredde" så lenge vi er enige om at det betyr "vi vil ikke telle byte" og ikke noe mer. Det er umålt, ikke uendelig. Kontrollene som former din opplevelse, ligger i CPU-aksjer, I/O-begrensninger, prosessgrenser, samtidighetsgrenser og midlertidig portforming når du blir opptatt. Hvis du arkitekterer som en voksen—CDN foran, ressurser avlastet, dynamisk arbeid minimert og raskt—kan du leve lykkelig på en plan som markedsfører "ubegrenset" fordi du sjelden trenger å teste det. Hvis du arkitekterer som om du har kjøpt en dedikert kjørebane, vil du lære betydningen av "rettferdig bruk" første gang noen bryr seg om nettstedet ditt.
Slik opererer jeg. Jeg behandler opprinnelsen som en liten API som fortjener respekt. Jeg flytter tunge byte til steder bygget for egress, og jeg betaler for den egressen fordi det er skalaens kostnad. Jeg følger med på p95, ikke gjennomsnitt. Jeg holder et øye med samtidighet og et annet på den lange halen av forespørselstider. Jeg leser tjenestevilkårene som om det er et teknisk dokument og oversetter hver eufemisme til et tall. Jeg aksepterer at delt hosting er et overabonnert miljø med en strålende verdiforslag for små nettsteder og et sett med harde grenser for alt ambisiøst. Når ambisjonen kommer, flytter jeg fordi jeg velger å gjøre det, ikke fordi en fløyelsbestemmelse forteller meg at jeg må.
Hvis du har blitt brent av "ubegrenset," ikke klandre deg selv. Formuleringen er ment å være beroligende, og den fungerer. Bygg den lille, motstandsdyktige opprinnelsen. Sett en CDN foran. Avlast de tunge tingene. Kjenn dine tall og dine flaskehalser. Når dagen kommer at du trenger en VPS eller noe større, gjør flytten med en varm cache og et kjølig hode. Du vil aldri se på "ubegrenset båndbredde" på samme måte igjen, og det er poenget. Det var ikke et løfte. Det var en invitasjon til å gjøre det rette arbeidet.
