Je to uklidňující text ve prodejním trychtýři, nikoli technická záruka. Když hostitel vytiskne „neomezeně“ na kartě plánu, neslibuje nekonečný přenos napříč fyzikou a rozpočty; slibují, že nezměří jednu konkrétní položku na vaší faktuře, zatímco kontrolují vše ostatní, co skutečně určuje, zda váš web zůstane rychlý a přístupný. Praktická pravda je jednoduchá a trochu iritující: váš plán nemusí měřit měsíční přenos, přesto vás bude absolutně měřit jinými způsoby, jakmile vaše využití vypadá neobvykle, špičkově nebo nákladně na obsluhu.
Viděl jsem, jak se to odehrává dostkrát, abych rozpoznal vzorec z prvního vlákna podpory. Stránka začíná silně, žebříčky stoupají, kampaň zasáhne a pak plán „neomezeně“ vyvine osobnost. Požadavky trvají déle. Statické prostředky se plazí. Pracovníci se hromadí. Chyby se objevují v kapsách, protože hostitel začíná chránit sdílené prostředí, ne váš úspěch. To není zlomyslnost; je to ekonomická realita. Hostitelé prodávají „neomezeně“, aby přilákali malé stránky, jejichž skutečné využití je malé a předvídatelné. Výjimky—video, stahování, veřejná API, špatně cachované aplikace—se stávají „zneužitím“ ve chvíli, kdy se grafy pohybují. Do hry vstupují podmínky služby a plánovače zdrojů. Pokud jste si koupili „neomezeně“ s očekáváním, že se rozběh rozšíří, budete se cítit zaskočeni. Pokud to považujete za nezměřené na papíře, ale velmi měřené v praxi, uděláte chytřejší rozhodnutí o architektuře a vyhnete se e-mailu o pozastavení, který vždy dorazí v nejméně vhodnou dobu.
Šířka pásma, přenos, propustnost a rychlost portu nejsou totéž
Je mi jedno, kolikrát průmysl zamění tyto pojmy—pokud budeme upřímní ohledně toho, co skutečně můžete přenést, musíme oddělit tuto terminologii. Šířka pásma je velikost potrubí v daném okamžiku. Propustnost je to, co skutečně dosáhnete přes toto potrubí po zahrnutí režie, souběhu a omezení. Přenos dat je celkové množství přenesené za určité období, obvykle měsíc. Rychlost portu je tvrdý strop pro okamžitý tok, obvykle vyjádřený jako 10 Mbps, 100 Mbps, 1 Gbps nebo více.
"Neomezený" je slib fakturace ohledně měsíčního přenosu, nikoli o okamžité rychlosti, kterou vaše pakety dosáhnou v poledne v pondělí. "Neomezený" je marketingový tah, který naznačuje, že neexistuje žádný strop, ale ve skutečnosti máte plán, který nepočítá gigabajty za překročení, ale omezuje vše ostatní: podíly CPU, I/O, počet procesů, souběžnost připojení a nakonec port, který vaše pakety musí projít. Port o rychlosti 1 Gbps může teoreticky v měsíci přenést obrovské množství, ale pokud hostitel tvaruje váš port na 100 Mbps po pěti minutách trvalé propustnosti—nebo vám jednoduše poskytne "dynamický" pruh, který se pod zátěží zmenšuje—váš teoretický přenos se vypařuje do reálného čekacího času a neúspěšných požadavků. Potrubí, které jste si mysleli, že jste koupili, je potrubí, které obsadíte pouze, když jste ticho.
Když hodnotím plán, neptám se "Je šířka pásma neomezená?" Ptám se na jinou, ošklivější otázku: "Jaká je nejhorší okamžitá propustnost, kterou mám zaručenou, když jsme všichni sousedé zaneprázdněni?" To je číslo, které zabrání zpoždění při nakupování, zpomalení obrázků a vytváření front opakovaných pokusů u pozadí úloh, za které později zaplatíte.
Jak je sdílený hosting navržen tak, aby vypadal neomezeně (dokud to tak není)
Sdílený hosting je trik na karnevalu postavený na průměrech. Většina stránek je drobná. Většina návštěvnosti je příležitostná v přátelských způsobech. Většina stránek je po prvním procházení uložena do mezipaměti. Tak hostitelé mohou nadměrně prodávat výpočetní výkon, paměť, úložiště I/O a síťové linky, zatímco stále poskytují veselé řídicí panely tisícům zákazníků. Za tímto iluzí se skrývají systémy plánovačů spravedlivého podílu a kvótové systémy. Podíly CPU brání jednomu účtu v tom, aby dlouho zabíral celý jádro. Tvarování IOPS zabraňuje hlučným sousedům v tom, aby vyhladověli SAN. Limity procesů PHP-FPM a Node zajišťují, že současně může být dynamicky zpracováno pouze několik požadavků. Stropy inode tiše omezují počet souborů, které můžete uchovávat na disku, a dusí mediálně náročné stránky, než se přenos vůbec objeví v grafu.
Kritická věc, které si musíte všimnout, je, že žádný z těchto systémů se nedotýká položky „šířka pásma“. Ta zůstává neměřená, takže tvrzení zůstává technicky pravdivé. Jakmile vaše aplikace začne vypadat zaneprázdněně na více než okamžik, pravidla spravedlivého podílu prosazují „typické použití“ tím, že škrtí části vašeho zásobníku, které ovládají. Uvidíte, jak se dynamické požadavky řadí do fronty, zatímco statické zdroje se cítí v pořádku. Pak se statické zdroje zpomalí, protože se původ stává úzkým hrdlem, které CDN nemůže zcela maskovat. Hostitel vám stále neúčtuje za přenos. Jen vás nutí používat méně tím, že snižují, jak rychle ho můžete poskytovat.
Nemyslím si, že by sdílení hostitelé byli za to záporáci. Model funguje pro naprostou většinu webových stránek a udržuje web levným pro malé vydavatele. Ale fráze „neomezená šířka pásma“ dává špatný mentální model. Vyzývá vás, abyste architektovali, jako byste měli vyhrazenou linku, a nemáte. Máte povolení nalévat vodu do kbelíku, aniž byste platili za litr, ale stále sdílíte kohoutek.
Drobným písmem, které skutečně řídí vaše použití
Pokud chcete pravdu, nečtěte cenovou tabulku; čtěte Pravidla přijatelného používání. Najdete tam sladce znějící fráze jako „typické webové stránky“ a „spravedlivé použití“, které se překládají jako „pokud začnete vypadat jako uzel pro sdílení souborů, streamovací stránka, mediální zrcadlo nebo centrum stahování, vyhrazujeme si právo vás omezit, přesunout nebo pozastavit.“ Najdete tam zákazy na streamování zvuku a videa z původu, distribuci souborů v měřítku, zálohy uložené na webovém prostoru, veřejně přístupné sbírky ZIP a „náročné“ skripty, které běží více než několik sekund každé. Najdete denní limity CPU v sekundách, stropy dotazů do databáze a počítání připojení, které činí váš oblíbený asynchronní prohledávač vypadat jako útok.
Limity vstupních procesů jsou obzvláště záludné. V prostředích ve stylu cPanel často „vstupní proces“ znamená „počet souběžných dynamických požadavků, které mohou začít.“ Dosáhněte tohoto stropu a další návštěvník se neřadí do fronty; dostane chyby. Limity I/O a čísla IOPS dělají totéž pro disk. Limity inode vás odříznou, když máte „příliš mnoho souborů,“ což ambiciózní mediální knihovny překročí, než se dotknou propustnosti. Žádná z těchto věcí neporušuje „neomezenou šířku pásma.“ Jen zajišťují, že ji použijete velmi málo, když vaše stránka začne růst.
Ztratil jsem počet plánů, které tvrdí, že jsou „neomezené,“ zatímco tiše nastavují CPU na „100 % jednoho jádra na několik sekund,“ I/O na „několik megabajtů za sekundu udržované“ a procesy na „několik najednou.“ To je opasek, kšandy a provaz. Pokud dosáhnete všech tří, neběžíte; ploužíte se.
Jak „neomezené“ vypadá v rušné pondělí
Představte si normální pondělí po víkendu, kdy zmínka přinese novou pozornost. Váš HTML je poměrně lehký, obrázky jsou slušné, spoléháte na CDN pro statické prostředky a váš původní server zpracovává dynamické prvky. Provoz se zvýší pětkrát. Zpočátku je vše v pořádku, protože cache jsou teplé a CDN řeší většinu požadavků na obrázky. Potom vaše dynamické koncové body zaostanou. Limit procesů hostitele udržuje aktivních pouze malé množství současných pracovníků PHP nebo Node. Začíná frontování a doby odezvy se prodlužují natolik, že způsobují přerušení časových limitů mezi službami. CDN stále pomáhá, ale ztráty v cache na HTML začínají bolet. Vaše databáze se stává více komunikativní a plánovač I/O odečítá další část, protože jste nyní „náročný na zdroje“. Vaši zákazníci, s dokonalým načasováním, klikají na obrázky, které nebyly v CDN teplé, což vyvolává nárazy z původu, které se srážejí s pomalou dynamickou prací.
Co se stane dál, závisí na hostiteli. Někteří hostitelé vás postupně omezují, dokud není výkon tak špatný, že návštěvníci vzdají a váš „průměr“ se vrátí k normálu. Jiní spustí automatizovaná pravidla zneužití a přesunou váš účet do nižší úrovně poolu nebo do karanténní VLAN. Někteří stále vrhají klasickou odpověď 509, „Překročený limit šířky pásma“, i když nepočítají bajty—509 je jen užitečná stopka, která kupuje čas, zatímco provádějí kontrolu. Výsledek se zdá být stejný: slib „neomezeného“ se vytratí přesně tehdy, když ho potřebujete.
Web, který převážně poskytuje cacheovaný HTML a statické prostředky, může přežít s naštvanými návštěvníky. Obchod s vysokým obsahem košíku nebo aplikace s vysokým obsahem vyhledávání to pocítí tvrdě. Bolest se zřídka objeví jako přehledná, jediná metrika. Je to mozaika malých zpomalení, která se sčítají do neúspěšných nákupů a rostoucího opouštění.
Než půjdeme hlouběji, chci vytvořit něco konkrétního a znovu použitelného, abyste viděli praktický strop, i když plán tvrdí, že neexistuje.
Ponořím se na pár minut do tvrdých čísel. Toto je prémiová sekce zaměřená přesně na matematiku, kterou můžete udělat na ubrousku, abyste přeložili rychlost portu na měsíční přenos a poté na zhlédnutí stránek. Pokud jste někdy bojovali s překladem „1 Gbps neměřený“ do „Kolik návštěv mohu skutečně obsloužit?“, tady to nabere jasnost.
Premium content
Přihlaste se pro pokračování
Tichí zabijáci: Throttling CPU, tvarování IOPS a omezení procesů
Pokud jste někdy cítili, že se stránka zpomalila, zatímco grafy vypadaly „normálně“, setkali jste se s tichými zabijáky. Throttling CPU je nejvíce viditelný, když víte, kam se dívat. Sdílené hostování přiděluje část jádra pro výbuchy a poté vás postupně snižuje pod trvalým zatížením. Vaše aplikace nespadne; pomalu se táhne. To stačí k tomu, aby kleslo hodnocení ve vyhledávání a míry konverze, aniž by se spustily alarmy, které by zapojily podporu.
Tvarování IOPS je jemnější. Databáze žijí a umírají podle latence úložiště. Aplikace těžké na soubory také. Hostitelé používají cgroups a QoS úložiště k tomu, aby velké útočníky udrželi od hladovění pole. Nevidíte chybu; vidíte, jak se dvacetimilisekundové čekání na disk změní na osmdesát, což přetahuje časy požadavků do nové, ošklivější distribuce. Spojte to s nízkým limitem vstupních procesů a vytvořili jste dokonalou mačku. Požadavky trvají déle, takže je více požadavků souběžných, což dříve narazí na limit, což odhodí nové návštěvníky na zem.
Omezení procesů je nakonec gilotina. Mnoho plánů omezuje PHP-FPM nebo podobné na hrstku dětí. Některé přidávají limit na celkový počet souběžných procesů na uživatele. Oba umožňují hostiteli usmívat se a slibovat „neomezenou šířku pásma“, zatímco zajišťují, že nemůžete, v praxi, poslat příliš mnoho. Pokud jste někdy pronásledovali fantomovou překážku na CDN nebo ve vašem aplikačním kódu, jen abyste zjistili, že hostitel povoluje osm pracovníků a končí, cítili jste past.
Neuvádím „neomezenou šířku pásma“ do svého registru rizik jako problém k vyřešení. Snížil jsem na ní svou závislost. Model, který funguje pro většinu malých a středně velkých stránek, je nudný a efektivní. Ukládejte HTML na okraji tak dlouho, jak to váš obsah dovolí. Tlačte obrázky, CSS a JS na CDN, kterou skutečně ověřujete v produkci s vysokou mírou zásahu, ne pouze s logem. Přeneste těžká média do objektového úložiště a nasměrujte tam svůj CDN, aby původ nikdy neviděl. Udržujte původ zaměřený na dynamické čtení a zápisy, které skutečně potřebují výpočet, a udělejte je co nejstateless a nejrychlejší.
Když to uděláte, plán „neomezená šířka pásma“ se stane přijatelným, protože nepožadujete, aby nesl zátěž, kterou nemůže nést bez dramatu. I když hostitel tvaruje váš původ, CDN absorbuje náhodnou povahu provozu. Vaše p95 se stabilizuje a získáte čas na volbu pohybu, když je růst skutečný, místo abyste reagovali během výpadku. Všechna drobná písma stále existují, ale nešlapete na ně. Vytvořili jste malý, obratný původ místo skladu.
Nikdy neukládám streamování videa, stahování souborů, veřejné zrcadlení softwaru nebo distribuci záloh na plán, který říká „neomezené“. Říkám to jako někdo, kdo se pokusil je propašovat a poté jednal s jazykem ToS po faktu. Tyto pracovní zátěže nejsou tím, na co je sdílené hostování stavěno, a hostitel vás vypne ve jménu ochrany ostatních. I když se vám to na chvíli podaří, jste jedno zmínění od stránek naštvaných emailů a migrace o půlnoci.
Těžké ZIP archivy produktových materiálů nebo výukových materiálů spustí stejné alarmy. Veřejné API, které povzbuzují klientské dotazování, také. A cokoliv, co povzbuzuje uživatele k opakovanému načítání stejného mnohamegabajtového souboru na nových připojeních, zasáhne tvarování portů rychleji, než si myslíte. Vlákno, které spojuje tyto případy, je jednoduché: jsou to vysokovýstupní, nízkopočtové pracovní zátěže, které útočí na tranzitní účet hostitele, aniž by spotřebovávaly CPU nebo I/O, které jejich plánovače jsou nastaveny měřit. Tento nesoulad je přesně důvod, proč „neomezená šířka pásma“ existuje jako fráze. Je to měkký slib, který má být odvolán okamžitě, když vaše použití přestane vypadat jako malý blog.
Chci vám dát překladovou příručku právníka s benchmarky, kterou si můžete ponechat. Další část je Prémiová Sekce, kde překládám nejběžnější klauzule, které hostitelé používají, do provozní reality. Pokud nebudete číst nic jiného, přečtěte si to, když procházíte plán ve 1 ráno a přemýšlíte, zda „neomezené“ unese vaše příští spuštění.
Premium content
Přihlaste se pro pokračování
Monitorování toho, na čem záleží, abyste věděli dříve, než dorazí e-mail o pozastavení
Přístrojová deska, kterou vám poskytne váš hostitel, vás neupozorní na nadcházející selhání. Bude hlásit průměry a součty, zatímco bolest se skrývá v dlouhém ocasu. Sledováním různých signálů. Výstup původu vs. výstup CDN mi říká, zda moje cache plní svou úlohu. Pokud výstup původu stoupá rychleji než návštěvy, vím, že něco je příliš agresivně obcházeno nebo pročišťováno. Souběžnost připojení je kanárek pro limity procesů; pokud se souběžná připojení blíží k plochému stropu, očekávám okamžité chyby pro nové návštěvníky. 95. percentil šířky pásma a doby žádosti je důležitější než průměry, protože předpovídají části dne, kdy vás hostitel bude omezovat a vaši uživatelé nedokončí svou cestu.
Čas krádeže CPU je testem zápachu ve sdíleném prostředí. Pokud vidím, že krádež stoupá během mých klidných hodin, vím, že soupeřím se sousedy a že můj výbuch přistane na unaveném uzlu. Pomalé dotazy vždy stojí za čas, který si myslíte, že nemáte; oprava jednoho špatného indexu může být rozdílem mezi přežitím zmínky a spálením dne omlouváním. Rozpočty chyb—počet chyb, které povolíte v okně, než považujete uživatelskou zkušenost za zhoršenou—všechny tyto věci spojují dohromady. Pokud se vaše chyby zvyšují dříve než provoz, máte neviditelné tření a „neomezené“ nic nezmírní.
Sledujte peníze a příběh přestane být záhadný. Transit je drahý, pokud nemůžete vyjednat skvělé propojení a pokud vaši uživatelé sedí daleko od vašich POPs. Sdílený hosting amortizuje tyto náklady mezi tisíce účtů, z nichž většina sotva něco používá. „Neomezené“ je nástroj pro získávání zákazníků. Snižuje tření a srovnává se dobře na tabulce, kde levnější plán „zahrnuje“ více. Hostitel předpokládá, že budete malí, nebo že uděláte rozumnou věc a přenesete svůj těžký provoz na CDN a objektové úložiště ve chvíli, kdy vyrostete, což přesouvá výstup na poskytovatele, který nedělá nic jiného než výstup.
Cloudy obrací model. Měří výstup, protože je to jejich středisko zisku a protože jejich sítě jsou nákladné na provoz v globálním měřítku. Neslibují „neomezené“, protože pobídka je jiná; chtějí, abyste navrhovali promyšleně a platili za to, co používáte. Sdílené hostitele chtějí, abyste přinesli svůj malý web a zůstali spokojeni, dokud nebudete malí, v tom okamžiku chtějí, abyste buď optimalizovali, nebo upgradovali. Nic z toho není cynické; je to způsob, jakým se platí účty. Ale vysvětluje to, proč jsou podmínky služby napsány sametovým jazykem a proč jsou technické limity vynucovány lehkým dotykem, dokud nejsou.
Rozhodovací body: kdy je „neomezené“ v pořádku, kdy je to bezohledné a jak migrovat
Nehazuji "neomezené" jen tak. Pro malou marketingovou stránku s převážně statickými stránkami a skromným blogem je to naprosto v pořádku, pokud před ní postavíte CDN. Pro obchod s lehkým provozem a rozumným cachováním to může fungovat, zatímco hledáte produkt-market fit. Pro publikaci, která má nepředvídatelné špičky, je to riskantní, pokud agresivně necacheujete a nepředrenderujete. Pro cokoli, co vydává velké soubory, je to špatný nástroj ode dne, kdy ho spustíte.
Můj rozhodovací strom je strohý. Pokud je vaše p95 dynamická doba odezvy nízká a zůstává nízká při lehkém zatížení, můžete používat sdílený plán déle, než si myslíte. Pokud je vaše CDN hit rate skutečně vysoká a váš původní egress zůstává plochý, když se provoz zdvojnásobí, jste dostatečně v bezpečí. Pokud některá z těchto podmínek selže, plánujte přesun nyní. Malý VPS s dvěma vCPU a dostatkem paměti, aby se zabránilo swapování, je nudný a spolehlivý. Poskytuje vám předvídatelnou souběžnost, lepší výkon úložiště a síťovou dráhu, které můžete skutečně rozumět. Stále můžete používat stejnou strategii CDN a objektového úložiště. Když to přerostete, pocítíte to způsoby, které můžete měřit a plánovat, a přejdete do dedikovaných nebo spravovaných clusterů, protože se tak rozhodnete, ne proto, že vás k tomu přinutila klauzule ToS.
Migrační cesta nemusí být dramatická. Udržujte svůj původ bezstavový, kde je to možné, aby byly přepínače DNS čisté. Ukládejte sezení do sdíleného backendu, na který můžete ukazovat jak ze starých, tak z nových původů během krátkého překrytí. Zahřejte cache před přepnutím, aby nový původ neobdržel celý náraz. Cílem není být dokonalý, ale předvídatelný. „Neomezené“ vás zklame nepředvídatelně. Vaším cílem je přestat být překvapován.
Sliboval jsem praktické, prožité scénáře, protože tak se hrany tohoto tématu stávají zřejmými. Další sekce je Prémiová sekce se třemi příběhy z reálného světa, každý začínající na „neomezeném“, každý narážející na jinou zeď a přesně popsané změny, které je stabilizovaly.
Premium content
Přihlaste se pro pokračování
Můj postoj, stručně: je to neměřené, ne neomezené — tak to berte
Nemám problém s „neomezenou šířkou pásma“, pokud se shodneme, že to znamená „nebudeme počítat bajty“ a nic víc. Je to neměřené, ne nekonečné. Ovládací prvky, které formují vaši zkušenost, jsou v podílech CPU, limitech I/O, omezeních procesů, stropu souběžnosti a tvarování efemérních portů, když se stanete zaneprázdněnými. Pokud architektujete jako dospělý—CDN vpředu, aktiva odložena, dynamická práce minimalizována a rychlá—můžete žít šťastně na plánu, který propaguje „neomezeně“, protože zřídka potřebujete to testovat. Pokud architektujete, jako byste si koupili vyhrazený pruh, naučíte se významu „spravedlivého použití“ poprvé, když se někdo začne zajímat o váš web.
Takto operuji já. Zacházím s původem jako s malým API, které si zaslouží respekt. Přesouvám těžké bajty na místa určená pro výstup, a za ten výstup platím, protože je to náklad škálování. Sleduji p95, ne průměry. Jedno oko mám na souběžnosti a druhé na dlouhém ocasu časů požadavků. Čtu Podmínky použití jako technický dokument a překládám každou eufemismu na číslo. Přijímám, že sdílený hosting je přeplněné prostředí s brilantním hodnotovým návrhem pro malé stránky a sadou tvrdých limitů pro cokoliv ambiciózního. Když přijde ambice, stěhuji se, protože chci, ne proto, že mi to nějaká jemná klauzule říká.
Pokud jste byli spáleni „neomezeným“, nekritizujte se. Formulace má být uklidňující, a funguje to. Vytvořte malý, odolný původ. Dejte před to CDN. Přesuňte těžké věci. Znáte své čísla a své úzké místa. Když přijde den, kdy potřebujete VPS nebo něco většího, přesuňte se se zahřátou cache a chladnou hlavou. Už nikdy se na „neomezenou šířku pásma“ nebudete dívat stejně, a to je ten bod. Nebyl to slib. Byla to výzva k tomu, abyste udělali správnou práci.