Cum compari VPS-uri: cost total, resurse și un protocol de testare

Compară soluții pentru aceeași aplicație

Două VPS-uri cu același număr de vCPU nu sunt automat echivalente. Prețul mașinii, limitele resurselor, regiunea, backup-ul și timpul de administrare descriu părți diferite ale deciziei. O comparație utilă începe cu aplicația care trebuie să funcționeze și cu o probă pe care o poți repeta. Acest ghid oferă o fișă de decizie și un protocol de evaluare; exemplele numerice sunt fictive, nu rezultate măsurate la furnizori.

Pentru un site de prezentare, întrebarea poate fi dacă paginile și formularul rămân disponibile în intervalele importante. Pentru un magazin, contează și consistența comenzilor, stocarea imaginilor, cozile și recuperarea bazei de date. Dacă introduci toate aceste proiecte într-un singur top bazat pe preț, pierzi tocmai informația care poate schimba alegerea.

Înainte să ceri oferte, scrie ce rulează pe server: aplicație, bază de date, procese de fundal, sarcini programate și fișiere persistente. Separă serviciile externe, precum emailul tranzacțional sau procesatorul de plăți. Un proces lent din afara serverului nu devine rapid doar pentru că ai cumpărat mai multă memorie.

O fișă tehnică ce poate fi verificată

Pentru fiecare ofertă notează data consultării, moneda, regiunea și planul exact. Apoi consemnează dacă procesorul este partajat sau dedicat, memoria alocată, capacitatea discului, traficul inclus și limitele relevante. Când o informație nu este publică, scrie „de confirmat” și cere clarificarea. Nu transforma o rubrică goală într-un avantaj presupus.

Întreabă cum se face redimensionarea. Este nevoie de oprire? Poți reveni la o configurație mai mică? Discul poate fi micșorat? Ce se întâmplă cu adresa IP? Răspunsurile pot schimba planul de creștere al aplicației. O opțiune de upgrade disponibilă în panou nu garantează că întregul proiect poate fi mutat fără intervenție.

Pentru administrare, verifică explicit cine actualizează sistemul, baza de date și aplicația. Termeni comerciali precum „managed” pot acoperi servicii diferite. Cere exemple concrete: cine investighează un disc plin, cine repornește un worker și cine restaurează o bază coruptă. Separă disponibilitatea infrastructurii de remedierea codului aplicației.

Păstrează oferta sau o captură datată împreună cu condițiile relevante. Pagina de prezentare, coșul de comandă și factura pot arăta sume diferite prin promoții, taxe sau opțiuni suplimentare. Nu comparăm aici prețuri actuale ale unor furnizori; pentru cumpărare trebuie verificată oferta finală în configurația dorită.

Cost total: un calcul transparent

Folosim două variante fictive, exprimate în aceeași monedă și înaintea eventualelor taxe. Varianta A costă 40 lei pentru mașină, 10 lei pentru backup și 5 lei pentru adresă IP, lunar. Estimăm două ore de administrare la 100 lei pe oră. Costul de planificare este 40 + 10 + 5 + 200 = 255 lei lunar, adică 3060 lei pentru douăsprezece luni.

Varianta B costă 95 lei lunar, cu componentele de infrastructură din exemplu incluse, și necesită o oră de administrare evaluată la același tarif. Totalul este 195 lei lunar, adică 2340 lei anual. Dacă migrarea inițială ar costa ipotetic 500 lei, primul an ar ajunge la 2840 lei. Diferența față de A ar fi 220 lei în acest scenariu, nu diferența dintre prețurile afișate ale serverelor.

Aceste rezultate depind de ipoteze. Dacă timpul de administrare pentru A ar fi doar o jumătate de oră, costul lunar ar deveni 105 lei. De aceea trebuie să păstrezi timpul estimat separat de costurile facturate. Nu prezenta estimarea drept economie garantată și nu presupune că suportul inclus elimină orice muncă proprie.

În fișa ta adaugă separat trafic suplimentar, stocare externă, monitorizare, licențe și intervenții. Dacă o componentă nu este necesară, marchează motivul. Dacă două variante oferă servicii diferite, explică diferența înainte să compari totalul. Un număr exact calculat din ipoteze incompatibile nu este o comparație exactă.

Construiește o probă care reprezintă utilizarea reală

Alege un mediu de test propriu sau pentru care ai autorizare și folosește date fictive. Nu lansa teste de încărcare pe site-uri publice ale furnizorilor și nu folosi producția ca laborator implicit. Definește o condiție de oprire dacă apar erori sau dacă resursele afectează alte servicii.

Pentru o aplicație cu catalog, un scenariu simplu poate cuprinde lista produselor, o pagină de produs și o căutare. Păstrează aceleași date, aceeași versiune de cod și aceleași configurări pentru ambele servere. Precizează dacă ai cache rece sau încălzit. Un rezultat obținut după încălzirea cache-ului nu trebuie comparat cu prima cerere după instalare pe cealaltă mașină.

Stabilește durata, nivelul de concurență și locul din care generezi traficul. Un generator suprasolicitat poate limita testul și poate ascunde capacitatea serverului. O regiune mai apropiată poate reduce latența de rețea fără să indice un procesor mai rapid. Notează aceste condiții, fiindcă altfel un coleg nu poate reproduce rezultatul.

Începe cu un volum mic pentru a verifica scenariul și conținutul răspunsurilor. Apoi crește controlat încărcarea până la nivelul ales pentru experiment. Nu confunda utilizatorii simultani, cererile pe secundă și vizitatorii pe zi: sunt mărimi diferite. O conversie între ele necesită ipoteze despre comportamentul utilizatorului și numărul de cereri.

Ce măsori și ce concluzii poți trage

Înregistrează numărul cererilor, rata erorilor și distribuția duratelor. Mediana descrie mijlocul distribuției, iar p95 ajută la observarea părții mai lente. Notează metoda de măsurare și numărul probelor; o percentilă din foarte puține observații nu justifică o concluzie puternică. Compară și consumul de procesor, memorie și disc în același interval.

Grafana k6 permite definirea unor praguri care stabilesc dacă un test trece sau eșuează. Alege pragurile după nevoile aplicației și declară-le înainte de test. Un răspuns HTTP rapid poate avea conținut greșit, deci verifică și rezultatul operației, nu numai timpul. Documentația oficială despre metrici și praguri este inclusă în sursele articolului.

Presupunem un set didactic: serverul A are p95 de 420 ms și 0,2% erori, iar B are p95 de 330 ms și 2% erori. Dacă regula stabilită cere sub 500 ms și sub 1% erori, A trece, iar B eșuează. Alegerea exclusiv după latență ar recompensa o variantă care nu livrează suficient de fiabil scenariul. Aceste cifre sunt inventate pentru interpretare, nu benchmark-uri comerciale.

Dacă ambele variante trec, rezultatul arată că ambele satisfac testul respectiv. Poți decide apoi după cost, recuperare și operare. Dacă ambele eșuează, investighează cauza înainte să cumperi un server mai mare. O interogare fără index sau o integrare externă lentă poate domina durata indiferent de oferta aleasă.

Backup-ul trebuie verificat printr-o restaurare

Întreabă ce anume este salvat: discul, baza de date, fișierele încărcate și configurația necesară pornirii. Notează frecvența, retenția, locul stocării și drepturile de acces. O copie aflată în același cont administrativ poate fi afectată de același incident. Un snapshot este util, dar nu trebuie confundat automat cu întregul plan de recuperare.

Proba practică se face într-o destinație separată. Restaurează date fictive, pornește aplicația și verifică o operație reprezentativă. Măsoară timpul până la funcționare, nu numai timpul de descărcare a arhivei. Dacă baza și fișierele provin din momente incompatibile, aplicația poate porni și totuși să fie incompletă.

Scrie două obiective: câtă informație poți pierde acceptabil și cât timp poți rămâne indisponibil. Acestea trebuie discutate cu proprietarul proiectului. Nu promite recuperare în zece minute doar pentru că panoul permite un clic pe Restore. Exercițiul trebuie să demonstreze durata în condițiile documentate.

Decizia finală încape într-o pagină

Încheie evaluarea cu cerințele obligatorii, rezultatele testului, costul estimat și riscurile încă deschise. Pentru fiecare risc notează o acțiune și un responsabil: de exemplu, confirmarea retenției backup-ului sau verificarea exportului datelor. O ofertă care nu îndeplinește o cerință obligatorie nu devine potrivită printr-un scor mediu mai bun.

Păstrează și motivul respingerii celorlalte variante. Când traficul sau echipa se schimbă, poți relua analiza fără să începi de la zero. Stabilește un declanșator de reevaluare, precum apropierea de limita de stocare sau depășirea repetată a pragului de răspuns în condiții comparabile. Nu schimba infrastructura doar pentru că o ofertă nouă are mai multe vCPU în titlu.

Fișa minimă de predare conține planul și regiunea, data ofertei, costurile și ipotezele, versiunea aplicației, datele și scenariul de test, rezultatele, proba de restaurare și concluzia limitată la aceste condiții. Acest dosar este mai valoros decât un clasament fără metodă: permite verificarea alegerii și arată ce trebuie măsurat din nou.