Este un text linistitor intr-un funnel de vanzari, nu o garantie tehnica. Cand un furnizor de hosting scrie „nelimitat” pe cardul planului, nu promite transfer infinit peste legile fizicii si bugetelor; promite ca nu va contoriza o anumita linie de pe factura, controland in acelasi timp tot restul care determina daca site-ul tau ramane rapid si accesibil. Adevarul practic este simplu si putin enervant: planul tau poate sa nu contorizeze transferul lunar, dar te va contoriza absolut in alte moduri in secunda in care utilizarea ta arata neobisnuit, cu varfuri sau costisitoare de servit.
Am urmarit acest lucru desfasurandu-se de suficiente ori incat sa identific tiparul inca din primul tichet de suport. Site-ul porneste bine, pozitiile in cautari urca, o campanie prinde, iar apoi planul „nelimitat” capata personalitate. Cererile dureaza mai mult. Resursele statice se tarsc. Workerii se blocheaza. Erorile apar pe alocuri pentru ca furnizorul incepe sa protejeze mediul partajat, nu succesul tau. Nu este rautate; este o realitate economica. Furnizorii vand „nelimitat” pentru a atrage site-uri mici a caror utilizare reala este minuscula si previzibila. Cazurile extreme — video, descarcari, API-uri publice, aplicatii prost cache-uite — devin „abuz” in momentul in care graficele se misca. ToS-ul si scheduler-ele de resurse intra in actiune. Daca ai cumparat „nelimitat” asteptandu-te la pista de decolare pentru a scala, te vei simti luat prin surprindere. Daca il tratezi ca necontorizat pe hartie, dar foarte contorizat in practica, vei lua decizii de arhitectura mai inteligente si vei evita emailul de suspendare care soseste intotdeauna in cel mai inoportun moment.
Bandwidth, transfer, throughput si viteza portului nu sunt acelasi lucru
Nu ma intereseaza de cate ori industria estompeaza termenii — daca vrem sa fim corecti despre ce poti impinge de fapt, trebuie sa separam vocabularul. Bandwidth-ul este dimensiunea conductei la un moment dat. Throughput-ul este ceea ce obtii de fapt prin acea conducta dupa overhead, congestie si limitare. Transferul de date este cantitatea totala mutata pe o anumita perioada, de obicei o luna. Viteza portului este plafonul absolut al fluxului instantaneu, exprimat de obicei ca 10 Mbps, 100 Mbps, 1 Gbps sau mai mult.
„Necontorizat” este o promisiune de facturare despre transferul lunar, nu despre rata instantanee pe care pachetele tale o obtin la pranz luni. „Nelimitat” este un artificiu de marketing care sugereaza ca nu exista plafon, dar ceea ce ai de fapt este un plan care nu totalizeaza gigaoctetii pentru suprataxa, in timp ce aplica limite prin orice altceva: cote de CPU, I/O, numar de procese, concurenta conexiunilor si, in cele din urma, portul prin care pachetele tale trebuie sa treaca. Un port de 1 Gbps poate, teoretic, muta o cantitate masiva intr-o luna, dar daca furnizorul iti limiteaza portul la 100 Mbps dupa cinci minute de throughput sustinut — sau pur si simplu iti da o banda „burstable” care scade sub sarcina — transferul tau teoretic se evapora in timp real de asteptare si cereri esuate. Conducta pe care credeai ca ai cumparat-o este conducta pe care o ocupi doar cand esti linistit.
Cand evaluez un plan, nu intreb „Este bandwidth-ul nelimitat?” Pun o intrebare diferita, mai urata: „Care este throughput-ul instantaneu in cel mai rau caz care mi se garanteaza cand vecinii si eu suntem toti ocupati?” Acesta este numarul care impiedica checkout-ul sa se blocheze, imaginile sa se tareasca si job-urile de fundal sa construiasca o coada de reincercari pentru care vei plati mai tarziu.
Cum este proiectat hosting-ul partajat sa para nelimitat (pana cand nu mai este)
Hosting-ul partajat este un truc de carnaval construit pe medii. Cele mai multe site-uri sunt minuscule. Cel mai mult trafic este cu varfuri in moduri prietenoase. Cele mai multe pagini sunt in cache dupa prima accesare. Asa pot furnizorii sa suprasubscrie calcul, memorie, I/O de stocare si benzi de retea servind in acelasi timp panouri vesele la mii de clienti. Mecanismul din spatele acestei iluzii este un cuib de schedulere cu partajare echitabila si sisteme de cote. Cotele de CPU impiedica un singur cont sa ia un nucleu intreg pentru mult timp. Modelarea IOPS tine utilizatorii zgomotosi sa nu infometeze array-ul. PHP-FPM si limitele de procese Node asigura ca doar un numar mic de cereri pot fi executate dinamic simultan. Plafoanele de inode-uri limiteaza silentios numarul de fisiere pe care le poti pastra pe disc, sugrumand site-urile cu multe media inainte ca transferul sa apara vreodata intr-un grafic.
Lucrul critic de observat este ca niciunul dintre aceste sisteme nu atinge linia de „bandwidth”. Aceasta ramane necontorizata, asa ca afirmatia ramane tehnic corecta. In momentul in care aplicatia ta incepe sa arate ocupata pentru mai mult de un moment, regulile de partajare echitabila aplica „utilizare tipica” prin limitarea partilor din stack-ul tau pe care le controleaza. Vei vedea cereri dinamice care se pun la coada in timp ce resursele statice par in regula. Apoi resursele statice incetinesc pentru ca originea devine bottleneck-ul pe care un CDN nu il poate masca complet. Furnizorul tot nu te taxeaza pentru transfer. Pur si simplu te face sa folosesti mai putin din el prin reducerea vitezei cu care il poti servi.
Nu cred ca furnizorii de hosting partajat sunt raufacatori pentru asta. Modelul functioneaza pentru marea majoritate a site-urilor web si a mentinut web-ul ieftin pentru editorii mici. Dar expresia „bandwidth nelimitat” da un model mental gresit. Te invita sa arhitectezi ca si cum ai avea o banda dedicata, si nu ai. Ai permisiunea sa torni apa intr-o galeata fara sa platesti pe litru, dar impartesti robinetul.
Litere mici care guverneaza de fapt utilizarea ta
Daca vrei adevarul, nu citi tabelul de preturi; citeste Politica de Utilizare Acceptabila. Vei gasi expresii dulci precum „site-uri tipice” si „utilizare echitabila”, care se traduc in „daca incepi sa arati ca un nod de partajare fisiere, un site de streaming, o oglinda de media sau un hub de descarcari, ne rezervam dreptul sa te limitam, migram sau suspendam.” Vei gasi interdictii privind streaming-ul audio si video de la origine, distributia de fisiere la scara, arhivele de backup stocate pe spatiul web, colectiile de ZIP accesibile public si scripturile „intensive in resurse” care ruleaza mai mult de cateva secunde fiecare. Vei gasi limite zilnice de secunde CPU, plafoane de interogari la baza de date si numararea conexiunilor care face crawler-ul tau asincron preferat sa arate ca un atac.
Limitele de procese de intrare sunt deosebit de vicleane. In mediile de tip cPanel, un „proces de intrare” inseamna adesea „numarul de cereri dinamice concurente permise sa porneasca.” Atinge acel plafon si urmatorul vizitator nu se pune la coada; primeste erori. Limitele de I/O si numerele IOPS fac acelasi lucru cu discul. Limitele de inode-uri te taie cand ai „prea multe fisiere”, pe care bibliotecile media ambitioase le ating inainte sa atinga throughput-ul. Nimic din toate acestea nu incalca „bandwidth nelimitat”. Doar asigura ca folosesti foarte putin din el cand site-ul tau incepe sa creasca.
Am pierdut numarul planurilor care pretind „nelimitat” in timp ce seteaza silentios CPU la „100% dintr-un nucleu pentru cateva secunde”, I/O la „cativa megaocteti pe secunda sustinut” si procesele la „o mana la un moment dat.” Asta este o centura, bretele si o franghie. Daca le atingi pe toate trei, nu alergi; te taresti.
Cum arata „nelimitat” intr-o luni aglomerata
Imagineaza-ti o luni normala dupa ce o mentiune de weekend iti aduce atentie proaspata. HTML-ul tau este rezonabil de usor, imaginile sunt decente, te bazezi pe un CDN pentru resursele statice, iar originea se ocupa de partile dinamice. Traficul creste de cinci ori. La inceput, totul este in regula pentru ca cache-urile sunt calde si CDN-ul mananca cele mai multe cereri de imagini. Apoi endpoint-urile tale dinamice raman in urma. Limita de procese a furnizorului pastreaza doar un numar mic de workeri PHP sau Node concurenti activi. Punerea la coada incepe, iar timpii de raspuns se intind suficient de mult incat sa rupa timeout-urile intre servicii. CDN-ul tot ajuta, dar lipsa din cache a HTML-ului incepe sa muste. Baza de date devine mai vorbareata, iar scheduler-ul de I/O scade inca o felie pentru ca esti acum „intensiv in resurse”. Clientii tai, cu un timing perfect, dau clic pe imagini care nu erau populare in CDN, tragand rafale de la origine care se ciocnesc cu munca dinamica lenta.
Ce se intampla mai departe depinde de furnizor. Unii furnizori te limiteaza progresiv pana cand performanta este atat de proasta incat vizitatorii renunta si „media” ta revine la normal. Altii declanseaza reguli automate de abuz si iti muta contul intr-un pool de nivel inferior sau un VLAN de carantina. Cativa inca arunca raspunsul clasic 509, „Limita de Bandwidth Depasita”, chiar daca nu numara octeti — 509 este doar un semn de stop util pentru a castiga timp in timp ce analizeaza. Rezultatul se simte identic: promisiunea de „nelimitat” se evapora exact cand ai nevoie de ea.
Un site care serveste in principal HTML cache-uit si resurse statice ar putea supravietui cu vizitatori enervati. Un magazin cu cos de cumparaturi sau o aplicatie cu cautare intensa va primi lovitura in plin. Durerea rareori apare ca un metric net, singular. Este un mozaic de incetiniri mici care se compun in checkout-uri esuate si abandonuri in crestere.
Inainte de a merge mai adanc, vreau sa fac ceva concret si reutilizabil, astfel incat sa poti vedea plafonul practic chiar si cand un plan pretinde ca nu exista.
Voi intra in numere concrete pentru cateva minute. Aceasta este o Sectiune Premium concentrata direct pe matematica pe care o poti face pe un servetel pentru a traduce viteza portului in transfer lunar si apoi in vizualizari de pagina. Daca ai avut vreodata dificultati sa traduci „1 Gbps necontorizat” in „Cate vizite pot servi de fapt?”, aici se clarifica totul.
Premium content
Autentifică-te pentru a continua
Ucigasii silentiosi: limitarea CPU, modelarea IOPS si limitele de procese
Daca ai simtit vreodata un site incetinind in timp ce graficele pareau „normale”, ai intalnit ucigasii silentiosi. Limitarea CPU este cea mai vizibila cand stii unde sa te uiti. Furnizorii de hosting partajat aloca o felie dintr-un nucleu pentru rafale si apoi te reduc sub sarcina sustinuta. Aplicatia ta nu se prabuseste; se tareste. Este suficient pentru a dauna pozitiilor in cautari si ratelor de conversie fara a declansa alarme care ar implica suportul.
Modelarea IOPS este mai subtila. Bazele de date traiesc si mor dupa latenta de stocare. Aplicatiile cu multe fisiere la fel. Furnizorii folosesc cgroups si QoS de stocare pentru a impiedica utilizatorii mari sa infometeze array-ul. Nu vezi o eroare; vezi o asteptare de disc de douazeci de milisecunde transformandu-se in optzeci, ceea ce trage timpii de cerere intr-o distributie noua, mai urata. Combina asta cu un plafon mic de procese de intrare si ai construit o cutie de strangere perfecta. Cererile dureaza mai mult, deci mai multe cereri sunt concurente, ceea ce atinge plafonul mai devreme, ceea ce arunca vizitatorii noi pe podea.
Limitele de procese, in final, sunt ghilotina. Multe planuri limiteaza PHP-FPM sau similar la un numar mic de copii. Unele adauga o limita la totalul proceselor concurente per utilizator. Ambele permit unui furnizor sa zambeasca si sa promita „bandwidth nelimitat” in timp ce se asigura ca nu poti, in practica, sa trimiti foarte mult. Daca ai urmarit vreodata un bottleneck fantoma la CDN sau in codul aplicatiei tale doar pentru a descoperi ca furnizorul permite opt workeri si considera ca este suficient, ai simtit capcana.
Nu pun „bandwidth nelimitat” in registrul meu de riscuri ca o problema de rezolvat. Imi reduc dependenta de el. Modelul care functioneaza pentru cele mai multe site-uri mici si medii este plictisitor si eficient. Cache-uieste HTML-ul la edge cat permite continutul tau. Impinge imaginile, CSS-ul si JS-ul catre un CDN pe care il validezi efectiv in productie cu o rata de acces ridicata, nu doar un logo. Descarca media grea catre stocare de obiecte si indreapta CDN-ul acolo astfel incat originea sa nu o vada niciodata. Pastreaza originea concentrata pe citiri si scrieri dinamice care au cu adevarat nevoie de calcul, si fa-le cat mai fara stare si cat mai rapide posibil.
Cand faci asta, planul „bandwidth nelimitat” devine acceptabil pentru ca nu ii ceri sa care sarcina pe care nu o poate cara fara drama. Chiar daca furnizorul iti limiteaza originea, CDN-ul absoarbe natura aleatorie a traficului. P95-ul tau se stabilizeaza, si castigi timp sa alegi o mutare cand cresterea este reala in loc sa reactionezi in timpul unei intreruperi. Toate literele mici inca exista, dar nu calci pe ele. Ai construit o origine mica si agila in loc de un depozit.
Nu pun niciodata streaming video, descarcari de fisiere, oglinzi publice de software sau distributie de backup-uri pe un plan care spune „nelimitat”. Spun asta ca cineva care a incercat sa le strecoare si apoi a negociat cu limbajul ToS-ului dupa fapt. Aceste sarcini de lucru nu sunt pentru ce este construit hosting-ul partajat, iar furnizorul te va opri in numele protejarii tuturor celorlalti. Chiar daca reusesti pentru scurt timp, esti la o mentiune distanta de pagini de emailuri furibunde si o migrare la miezul noptii.
Arhivele ZIP grele de resurse de produs sau materiale de invatare vor declansa aceleasi alarme. API-urile publice care incurajeaza polling-ul clientilor la fel. Si orice incurajeaza utilizatorii sa descarce repetat acelasi fisier de multi-megaocteti pe conexiuni proaspete va atinge limitarea portului mai repede decat crezi. Firul care conecteaza aceste cazuri este simplu: sunt sarcini de lucru cu iesire mare si calcul mic care ataca factura de tranzit a furnizorului fara sa consume CPU-ul sau I/O-ul pe care scheduler-ele lor sunt calibrate sa le masoare. Acea nepotrivire este exact de ce „bandwidth nelimitat” exista ca expresie. Este o promisiune moale construita sa fie revocata in momentul in care utilizarea ta nu mai arata ca un blog mic.
Vreau sa iti dau un ghid de traducere avocat-cu-benchmark-uri pe care sa il pastrezi. Urmatoarea sectiune este o Sectiune Premium unde traduc cele mai comune clauze pe care le folosesc furnizorii in realitate operationala. Daca nu citesti nimic altceva, citeste asta cand scanezi un plan la 1 noaptea si te intrebi daca „nelimitat” va sustine urmatorul tau lansament.
Premium content
Autentifică-te pentru a continua
Monitorizarea a ceea ce conteaza, astfel incat sa stii inainte de sosirea emailului de suspendare
Panoul de control pe care ti-l da furnizorul nu te va avertiza despre esecul care vine. Va raporta medii si totaluri in timp ce durerea se ascunde in coada lunga. Eu urmaresc semnale diferite. Iesirea de la origine versus iesirea de la CDN imi spune daca cache-ul isi face treaba. Daca iesirea de la origine creste mai repede decat vizitele, stiu ca ceva este ocolit sau purjat prea agresiv. Concurenta conexiunilor este canarul pentru limitele de procese; daca conexiunile concurente se apropie de un plafon fix, ma astept la erori imediate pentru vizitatorii noi. Bandwidth-ul si timpul de cerere la percentila 95 conteaza mai mult decat mediile pentru ca prezic partile din zi in care furnizorul te va limita si utilizatorii tai vor esua sa completeze o calatorie.
Timpul de furt CPU este un test de miros al mediului partajat. Daca vad furtul crescand in orele mele linistite, stiu ca ma bat cu vecinii si ca rafala mea va ateriza pe un nod obosit. Interogarile lente merita intotdeauna timpul pe care crezi ca nu il ai; repararea unui index prost poate fi diferenta intre supravietuirea unei mentiuni si arderea unei zile cerandu-ti scuze. Bugetele de erori — numarul de erori pe care le permiti intr-o fereastra inainte de a considera experienta utilizatorului degradata — leaga toate acestea impreuna. Daca erorile tale cresc inainte ca traficul sa o faca, ai frictiune invizibila, si „nelimitat” nu va amortiza nimic.
Urmareste banii si povestea nu mai este misterioasa. Tranzitul este costisitor daca nu poti negocia peering bun si daca utilizatorii tai stau departe de POP-urile tale. Hosting-ul partajat amortizeaza acel cost pe mii de conturi din care cele mai multe abia folosesc ceva. „Nelimitat” este un instrument de achizitie de clienti. Scade frictiunea si se compara bine intr-un tabel unde planul mai ieftin „include” mai mult. Furnizorul presupune ca vei fi mic, sau ca vei face lucrul sensibil si iti vei muta traficul greu catre un CDN si stocare de obiecte in momentul in care cresti, ceea ce muta iesirea catre un furnizor care nu face altceva decat iesire.
Cloud-urile inverseaza modelul. Contorizeaza iesirea pentru ca este centrul lor de profit si pentru ca retelele lor sunt costisitoare de operat la scara globala. Nu promit „nelimitat” pentru ca stimulentul este diferit; vor ca tu sa arhitectezi cu grija si sa platesti pentru ceea ce folosesti. Furnizorii de hosting partajat vor ca tu sa aduci site-ul tau mic si sa ramai fericit pana cand nu mai esti mic, moment in care vor ca fie sa optimizezi, fie sa faci upgrade. Nimic din toate acestea nu este cinic; asa se platesc facturile. Dar explica de ce ToS-ul este scris in limbaj de catifea si de ce limitele tehnice sunt aplicate cu o atingere usoara pana cand nu mai sunt.
Puncte de decizie: cand „nelimitat” este in regula, cand este nesabuit si cum sa migrezi
Nu resping „nelimitat” din start. Pentru un site de marketing mic cu pagini in principal statice si un blog modest, este perfect in regula daca pui un CDN in fata. Pentru un magazin cu trafic usor si cache sensibil, poate functiona in timp ce gasesti product-market fit. Pentru o publicatie cu varfuri imprevizibile, este riscant daca nu cache-uiesti si pre-renderezi agresiv. Pentru orice emite fisiere mari, este instrumentul gresit din ziua lansarii.
Arborele meu de decizie este direct. Daca timpul tau de raspuns dinamic p95 este mic si ramane mic sub stres usor, poti sta pe un plan partajat mai mult decat crezi. Daca rata ta de acces CDN este cu adevarat ridicata si iesirea de la origine ramane plata cand traficul se dubleaza, esti suficient de in siguranta. Daca oricare din aceste conditii esueaza, planifica mutarea acum. Un VPS mic cu doua vCPU-uri si suficienta memorie pentru a evita swap-ul este plictisitor si fiabil. Iti ofera concurenta previzibila, performanta de stocare mai buna si o banda de retea pe care o poti intelege cu adevarat. Poti folosi in continuare aceeasi strategie de CDN si stocare de obiecte. Cand depasesti asta, vei simti in moduri pe care le poti instrumenta si planifica, si vei trece la dedicat sau clustere gestionate pentru ca alegi sa o faci, nu pentru ca o clauza din ToS ti-a fortat mana.
Calea de migrare nu trebuie sa fie dramatica. Pastreaza originea fara stare acolo unde este posibil, astfel incat schimbarile DNS sa fie curate. Stocheaza sesiunile intr-un backend partajat pe care il poti indica de la ambele origini, veche si noua, in timpul unei scurte suprapuneri. Incalzeste cache-urile inainte sa faci comutarea, astfel incat noua origine sa nu ia toata explozia. Ideea nu este sa fii perfect; este sa fii previzibil. „Nelimitat” te dezamageste imprevizibil. Obiectivul tau este sa nu mai fii surprins.
Am promis scenarii practice, traite, pentru ca asa devin evidente marginile acestui subiect. Urmatoarea sectiune este o Sectiune Premium cu trei povesti din lumea reala, fiecare pornind de la „nelimitat”, fiecare lovind un alt perete, si schimbarile exacte care le-au stabilizat.
Premium content
Autentifică-te pentru a continua
Pozitia mea, pe scurt: este necontorizat, nu nelimitat — trateaza-l asa
Nu am nimic impotriva „bandwidth nelimitat” atat timp cat suntem de acord ca inseamna „nu vom totaliza octetii” si nimic mai mult. Este necontorizat, nu infinit. Controalele care iti modeleaza experienta traiesc in cotele de CPU, limitele de I/O, limitele de procese, plafoanele de concurenta si modelarea efemera a portului cand devii ocupat. Daca arhitectezi ca un adult — CDN in fata, resurse descarcate, munca dinamica minimizata si rapida — poti trai fericit pe un plan care promoveaza „nelimitat” pentru ca rareori ai nevoie sa il testezi. Daca arhitectezi ca si cum ai cumparat o banda dedicata, vei invata sensul de „utilizare echitabila” prima data cand cuiva ii pasa de site-ul tau.
Iata cum operez eu. Tratez originea ca un mic API care merita respect. Mut octetii grei in locuri construite pentru iesire si platesc pentru acea iesire pentru ca este costul scalarii. Urmaresc p95, nu medii. Tin un ochi pe concurenta si altul pe coada lunga a timpilor de cerere. Citesc ToS-ul ca pe un document tehnic si traduc fiecare eufemism intr-un numar. Accept ca hosting-ul partajat este un mediu suprasubscris cu o propunere de valoare geniala pentru site-uri mici si un set de limite dure pentru orice ambitios. Cand ambitia soseste, ma mut pentru ca aleg sa o fac, nu pentru ca o clauza de catifea imi spune ca trebuie.
Daca ai fost lovit de „nelimitat”, nu te bate pe tine. Formularea este menita sa fie linistitoare, si functioneaza. Construieste originea mica si rezilienta. Pune un CDN in fata. Descarca lucrurile grele. Cunoaste-ti numerele si punctele de sugrumare. Cand vine ziua in care ai nevoie de un VPS sau ceva mai mare, fa mutarea cu un cache cald si un cap rece. Nu vei mai privi niciodata „bandwidth nelimitat” la fel, si acesta este scopul. Nu a fost o promisiune. A fost o invitatie sa faci munca corecta.
