Calcolatore Risorse VPS

Prima il carattere del carico, non il nome del pacchetto

Quando si sceglie un VPS, il nome del pacchetto inganna facilmente. “Basic”, “standard”, “premium”, “general purpose”… Sembrano belli. Ma nessuno di questi nomi, da solo, dice quanto RAM consumerà il sito, quando soffocherà la CPU o in quale giorno il disco si riempirà.

Un sito statico e un negozio WooCommerce, anche se ricevono lo stesso numero di visitatori, non hanno bisogno dello stesso server. Nel primo si servono file pronti; nel secondo ci sono carrello, pagamento, scorte, sessioni utente, query al database, pannello di amministrazione e talvolta processi in coda in background. È qui che sta la differenza.

Questo modello di calcolo legge il VPS attraverso quattro risorse principali: vCPU, RAM, disco e traffico mensile. Ma non le considera come numeri grezzi; le valuta insieme al tipo di applicazione, al livello dell'ambiente, all'uso di cache/CDN, ai servizi che girano nello stesso VPS, ai log, ai backup locali e al margine di crescita.

Non esiste un'unica “formula ufficiale per il VPS”. Del resto, anche nella documentazione dei grandi provider cloud la questione viene affrontata così: CPU, memoria, rete e storage si considerano insieme; le famiglie di macchine sono distinte in base al carico di lavoro. Le macchine generiche si comportano in un modo, quelle orientate al calcolo in un altro, quelle orientate alla memoria in un altro ancora. Sul lato VPS vale la stessa logica, solo su scala più piccola.

flowchart LR
  A["Tipo di applicazione"] --> E["Stima delle risorse"]
  B["Traffico e cache"] --> E
  C["Database, worker, pannello di amministrazione, Docker"] --> E
  D["Disco, log, backup, margine di crescita"] --> E
  E --> F["vCPU"]
  E --> G["RAM"]
  E --> H["Disco"]
  E --> I["Traffico mensile"]

La frase che odio di più in questo tipo di calcoli è: “2 vCPU bastano.” Bastano per cosa? Per un sito statico, per WooCommerce, per Odoo, per un'API Node, o per un'installazione mista con MySQL, Redis, mail e Docker sulla stessa macchina?

Inoltre, sfugge la differenza tra CPU condivisa e CPU dedicata. Nei piccoli piani VPS la CPU è quasi sempre condivisa. Per siti web leggeri potrebbe non essere un problema. Ma su sistemi che eseguono worker regolari, che ricevono picchi di traffico, che generano report o che caricano frequentemente il database, lo stesso numero di vCPU può risultare più debole del previsto.

Per questo l'output di questo calcolo non è un “piano definitivo”, ma una stima di partenza sicura. Fornisce una buona prima fotografia per la scelta delle risorse. In produzione, l'ultima parola spetta ancora alle metriche: utilizzo CPU, consumo RAM, riempimento disco, traffico di rete, query lente, log degli errori, coda dei worker.

La carta è una cosa, il server è un'altra.

Da dove cominciamo?

La prima distinzione del calcolo deriva dal tipo di applicazione. Perché il carico di base di ogni classe di applicazione non è lo stesso.

Il sito statico si trova sul lato più leggero. Si assume una CPU di base di 1 vCPU e una RAM di base di 1 GB; anche il fattore CPU è mantenuto basso, a 0.2. Ha senso. Perché su un sito statico ben cachato, il server serve per lo più file pronti e il livello applicativo lavora pochissimo.

Per WordPress/blog la base sale: CPU di base 1.5 vCPU, RAM di base 2 GB, fattore CPU 1. WordPress ha una base PHP e database. Tra tema, plugin, elaborazione immagini, operazioni di amministrazione, ricerca, commenti, non si comporta come un sito statico. Tuttavia, con una cache adeguata, può essere notevolmente alleggerito.

WooCommerce/e-commerce è un'altra classe. In questo modello si prendono CPU di base 2.5 vCPU, RAM di base 4 GB, fattore CPU 2. Se mi chiedete, questa distinzione è indispensabile per l'e-commerce. Perché WooCommerce aggiunge al WordPress semplice il carrello, il pagamento, gli ordini, le scorte e il livello di iscrizione. Inoltre, alcune pagine non sono adatte alla cache completa. La pagina prodotto può arrivare dalla cache, ma sul carrello e sul pagamento la situazione cambia.

Per applicazioni Laravel/PHP e Node.js/API la CPU di base è 2 vCPU, la RAM di base 3 GB, il fattore CPU 1.2. Qui il bisogno reale dipende molto dal codice. Un'API semplice può girare molto leggera; un'applicazione che parla con servizi esterni, elabora dati continuamente e usa code può essere molto più pesante nella stessa classe.

Per una piccola SaaS la CPU di base è 3 vCPU, la RAM di base 4 GB, il fattore CPU 1.8. Sessioni utente, lavori in background, notifiche, report e traffico al database di solito arrivano insieme. Il numero di visitatori può sembrare basso, ma le operazioni interne all'applicazione sono molte. Se la si guarda come un sito web, si sceglie il pacchetto sbagliato.

I sistemi simili a Odoo/ERP sono sul lato pesante: CPU di base 4 vCPU, RAM di base 8 GB, fattore CPU 3. Nelle installazioni Odoo, la pianificazione di worker e memoria viene già considerata a parte. Reportistica, sessioni utente, moduli, operazioni sul database e attività di lunga durata distinguono questa classe dal normale sito blog.

Per un game server la CPU di base è 3 vCPU, la RAM di base 4 GB, il fattore CPU 2.5; per bot/worker si assumono CPU di base 2 vCPU, RAM di base 2 GB, fattore CPU 1.5. Soprattutto nei lavori di tipo worker, il numero di visitatori può essere fuorviante. Anche se nessuno entra nel sito, in background si stanno elaborando dati.

La scelta dell'ambiente si sovrappone al valore base come un coefficiente. Ambiente di test/hobby 0.75, piccola produzione 1, produzione 1.25, preparazione all'alta disponibilità 1.6. Preparazione all'alta disponibilità non significa che “il singolo VPS è diventato HA”, significa solo lasciare un margine di risorse più ampio. La vera HA richiede un'architettura separata.

Anche il margine di crescita entra in gioco alla fine. Il default è il 30%. Secondo me è ragionevole. È un buon intervallo per coprire un'attesa di crescita di 3-6 mesi. Si può inserire il 300%, ma se non si prevede davvero una crescita simile, il calcolo diventa un calcolo della paura.

Calcolo del traffico: la media mensile inganna un po'

Il numero di visitatori mensili è il primo dato da guardare, ma è debole per la decisione finale. Due siti con 100.000 visitatori potrebbero non produrre lo stesso carico. Uno mostra 1,5 pagine per visitatore, una dimensione pagina di 1 MB, e la CDN funziona bene. L'altro mostra 4 pagine per visitatore, una dimensione pagina di 3 MB e molte aree dinamiche. Stesso visitatore, carico sul server completamente diverso.

Il calcolo del traffico considera insieme il numero di visitatori, il valore pagine/sessione e la dimensione media della pagina. Si sottrae l'effetto della cache, si aggiunge il margine di crescita e il risultato viene convertito in GB. Il valore finale viene arrotondato a scaglioni di 50 GB; anche negli scenari più piccoli viene mostrato un traffico minimo di 50 GB.

Le assunzioni lato cache sono queste: senza cache risparmio 0, cache di base 35%, cache di pagina + object cache 60%, CDN + cache potente 75%. Non sono valori di garanzia ufficiali. Quando si usa NGINX cache o CDN, ci si aspetta una riduzione del carico sul server di origine; ma il risparmio effettivo dipende dal tasso di cache hit, dalla struttura della pagina e dalle aree dinamiche.

Prestate attenzione soprattutto in WooCommerce. Solo perché c'è la CDN, il carrello e la pagina di pagamento non diventano improvvisamente gratis. In aree come contenuti personalizzati, sessioni, operazioni di amministrazione, flusso di pagamento, controllo scorte, la cache è più limitata. La cache è un buon freno, non sostituisce il motore.

C'è anche il moltiplicatore delle ore di punta. Il traffico mensile non è distribuito uniformemente. Giorni di campagna, invio di newsletter, condivisioni sui social, picchi improvvisi sui siti di notizie… Mentre il valore medio sembra tranquillo, il server può sudare per un'ora. In questo calcolo, il Peak RPS si trova approssimativamente dividendo (visitatori mensili × pagine/sessione × moltiplicatore delle ore di punta) per il numero di secondi in 30 giorni. 30 giorni fanno 2.592.000 secondi.

L'effetto del traffico sulla CPU è ancora più interessante. Il numero di visitatori viene rapportato a 50.000, moltiplicato per il fattore CPU, si aggiunge il moltiplicatore delle ore di punta e si sottrae la metà dell'effetto cache dal lato CPU. Quindi la cache riduce seriamente il traffico, ma l'effetto sulla CPU viene ridotto in modo più prudente. Secondo me è l'approccio giusto, perché non tutte le richieste arrivano dalla cache.

Nel test di un sito statico cachato, con 100.000 visitatori mensili, 1,5 pagine/sessione, dimensione pagina 1 MB, moltiplicatore ore di punta 2, CDN + cache potente e margine di crescita del 20%, il risultato rimane a livello di 1 vCPU, 2 GB RAM, 40 GB disco, 50 GB di traffico mensile. C'è traffico, ma il carico è leggero.

Nell'esempio e-commerce non c'è la stessa comodità. Con 200.000 visitatori mensili, 4 pagine/sessione, dimensione media della pagina 3 MB, moltiplicatore ore di punta 5, cache di pagina + object cache e margine di crescita del 50%, il traffico mensile sale a 1450 GB. La raccomandazione CPU è 32 vCPU. A prima vista può sembrare alto; ma mettendo i numeri in fila, il quadro si fa duro: più visitatori, più pagine, pagine più grandi, carico di lavoro più pesante, picco più alto.

La dimensione della pagina è un altro problema. Non basta dire “il sito è leggero”, bisogna misurarlo. Immagini grandi, font, script di terze parti, codice pubblicitario, tag di analytics, file JS inutili gonfiano il traffico. Il fatto che si apra velocemente nel browser non significa che il trasferimento dati sia piccolo.

Chi lavora nella stessa macchina?

Nei piccoli VPS, la vera battaglia spesso nasce qui. Il server web non sta da solo. Anche MySQL sta lì, Redis, il pannello, forse anche il servizio di posta. E se si aggiungono container Docker e processi worker, 2 GB di RAM perdono il respiro.

Se il database è nello stesso VPS, il modello aggiunge un carico extra di RAM. La dimensione del database si divide per 20; il risultato viene limitato a un minimo di 1 GB e un massimo di 8 GB. Per esempio, anche per un database di 5 GB si riserva 1 GB di RAM. Per 30 GB di database si crea un extra di circa 1,5 GB. Sul lato CPU, si aggiungono 0,5 vCPU per il database.

Questi valori non sono un calcolo di tuning del database. Se gli indici sono pessimi, le query lunghe, se ci sono lock sulle tabelle, 0,5 vCPU non bastano. Ma per la pianificazione iniziale, è meglio che considerare il database come “a costo zero”.

Se Redis/object cache è nello stesso VPS, si aggiungono 0,5 GB alla RAM. Redis gira in memoria; dimenticandolo, si vedono strane lentezze su server piccoli. È stato installato per migliorare le prestazioni della cache, sì, ma richiede anch'esso RAM.

Per il pannello di amministrazione ci sono tre livelli: nessuno, pannello leggero, pannello completo tipo cPanel/Plesk. Un pannello leggero aggiunge 0,3 GB di RAM e 0,15 vCPU di CPU. Un pannello completo aggiunge 1 GB di RAM e 0,3 vCPU. Installare sistemi come cPanel o Plesk su un VPS con 1 GB di RAM e poi aspettarsi prestazioni dall'applicazione non è una buona idea. Il pannello offre comodità; la si paga con le risorse.

Il numero di worker/queue ha un impatto diretto. Per ogni worker si aggiungono 0,5 GB di RAM e 0,5 vCPU. Può sembrare un po' alto, ma ha senso se i lavori in background sono seri. Elaborazione immagini, generazione report, recupero dati da API esterne, svuotamento della coda email, attività post-pagamento… Se il worker non sta fermo, consuma risorse.

Se il servizio di posta elettronica gira nello stesso VPS, si aggiungono 0,5 GB di RAM e 0,3 vCPU. A parte le risorse, il servizio di posta è anche operativamente problematico. DNS, SPF, DKIM, DMARC, spam, coda, recapitabilità. Questo calcolo vede solo la quota di risorse, non calcola il mal di testa.

Per l'uso di Docker/container si aggiungono 0,5 GB di RAM e 0,2 vCPU. Docker porta ordine, ma non è gratis. Se il limite di memoria di Docker, il comportamento dello swap e la quota CPU non sono impostati correttamente, un container può comprimere l'intera macchina. “Abbiamo fatto il container, siamo sollevati” non è sempre la frase giusta.

L'essenza del calcolo CPU è questa: si prende il maggiore tra la CPU di base e il fabbisogno CPU da traffico, si aggiungono i carichi CPU dei servizi, si applicano il coefficiente dell'ambiente e il margine di crescita. Per la RAM, si sommano la RAM di base e la RAM dei servizi, aggiungendo di nuovo ambiente e margine di crescita. Poi il risultato viene arrotondato a scaglioni pratici di pacchetto: per la CPU 1, 2, 4, 6, 8, 12, 16, 24, 32, 64; per la RAM 1, 2, 4, 8, 16, 32, 64, 128 GB.

Non esiste un mondo con i decimali. Se esce un bisogno di 5,3 GB di RAM, si guarda a 8 GB. Se escono 3,1 vCPU, 4 vCPU hanno senso. Fare calcoli al millimetro in un ambiente di produzione avvicina al muro al minimo oscillazione.

Sul disco, il carico più pesante a volte sono le cose invisibili

Solo perché la cartella del codice è piccola, si pensa che il bisogno di disco sia piccolo. È un errore di calcolo che vediamo spesso. Applicazione 3 GB, media 10 GB; si dice “bastano 20 GB di disco”. Poi arrivano log, database, backup locale, file di sistema, immagini container, file temporanei.

Il calcolo del disco si fa con file dell'applicazione, media/upload, dimensione del database, log giornaliero, giorni di conservazione dei log e copie di backup locale. Se il database non è nello stesso VPS, non entra nel calcolo del disco. Se è nello stesso VPS, entra.

Prima si crea un subtotale del disco: file applicazione + file media + database (se nello stesso VPS) + log giornaliero × giorni di conservazione. Poi si considera il numero di copie di backup locale. Un backup locale aumenta approssimativamente di una volta il dataset. Si aggiunge una quota di sistema di 15 GB, si applica un margine di sicurezza del 20%, si aggiunge anche il margine di crescita. Il risultato viene arrotondato a scaglioni di 10 GB e si raccomanda un minimo di 20 GB.

La quota di sistema di 15 GB non deve sembrare piccola. Sistema operativo, pacchetti, residui di aggiornamento, file temporanei, log dei servizi, immagini Docker, file temporanei del database occupano spazio da lì. In produzione, il disco non è solo la vostra cartella di upload.

Anche i log sono insidiosi. 0,5 GB di log al giorno e 14 giorni di conservazione fanno 7 GB. 2 GB di log al giorno e 30 giorni di conservazione fanno 60 GB. Crescono in silenzio. Il disco supera l'80%, poi il 90, e poi durante un deploy arriva il famoso errore: no space left on device.

Il backup locale richiede anche attenzione. Tenere il backup sullo stesso disco non è una garanzia completa in uno scenario di disastro; se il disco va via, anche il backup se ne va. Ma una copia locale può servire per un rapido ripristino. Il modello lo include nel calcolo delle risorse. Decisioni come backup remoto, storage a oggetti, server di backup separato vanno pianificate a parte.

Nel test production WordPress, con 5 GB di file applicazione, 10 GB di media, 5 GB di database, 0,5 GB di log al giorno, 14 giorni di conservazione, 1 backup locale e margine di crescita del 30%, viene raccomandato un disco di 90 GB. A prima vista sembra tanto. Ma aggiungendo log, backup, quota di sistema e margine di sicurezza, non è troppo, è più che prudente.

Sul lato e-commerce il quadro cresce: 10 GB di file applicazione, 80 GB di media, 30 GB di database, 2 GB di log al giorno, 30 giorni di conservazione, 1 backup locale e margine di crescita del 50%. Il disco risultante è 480 GB. Se immagini prodotto, dati ordini, log e backup stanno nella stessa macchina, questo risultato non sorprende.

Lesinare troppo sul disco è un brutto vizio. Se la CPU non basta, vedete rallentamenti. Se la RAM non basta, parte lo swap. Se il disco si riempie, i servizi a volte si guastano in modo molto più netto: il database non riesce a scrivere, il log non si crea, il file di sessione non si apre, il deploy resta a metà. Peggio ancora, l'errore non sempre si spiega chiaramente.

Quando si traduce il risultato in un pacchetto

L'output ha quattro valori principali: CPU, RAM, disco e traffico mensile. Non metteteli nello stesso sacco. Ognuno indica un limite diverso.

La CPU è la potenza di elaborazione istantanea. Richiesta PHP, risposta API Node.js, query al database, compito di un worker, operazione post-pagamento… Queste toccano la CPU. Quando il traffico aumenta, la CPU può aumentare; la cache può ridurlo, ma non lo cancella del tutto.

La RAM è lo spazio dei servizi in esecuzione. MySQL, Redis, PHP-FPM, processi Node.js, pannello, container Docker, servizio di posta, worker. Quando la RAM diminuisce, il sistema può cadere nello swap. Fa finta di funzionare, ma rallenta. Soprattutto nelle applicazioni dinamiche, questa differenza si sente subito.

Il disco è l'archiviazione permanente. File dell'applicazione, media, database, log, backup e file di sistema guardano lì. Nel calcolo del disco, bisogna pensare non alla dimensione di oggi, ma all'accumulo tra qualche mese.

Il traffico mensile è il trasferimento dati. CDN, cache e ottimizzazione delle pagine lo riducono. La politica del traffico del provider va verificata a parte: c'è una quota, c'è un costo per eccedenza, c'è una riduzione di velocità? Il calcolo dà il bisogno in GB; non dà la condizione commerciale del provider.

In questo modello, i valori grezzi vengono arrotondati a scaglioni pratici di pacchetto. Se c'è un bisogno grezzo di 3,4 vCPU, si consigliano 4 vCPU. Se c'è bisogno di 9 GB di RAM, si può salire a 16 GB. Anche il disco si porta a scaglioni di 10 GB. Questo arrotondamento a volte mostra un risultato più grande del reale, ma i pacchetti VPS non si vendono comunque con i decimali.

E poi c'è questo: 4 vCPU potrebbero non comportarsi come 4 vCPU su ogni provider. Generazione della CPU, struttura condivisa/dedicata, strato di virtualizzazione, tipo di disco, qualità della rete, macchine vicine, tutto fa la differenza. Nella documentazione sulla scelta dei piani di provider come DigitalOcean, la distinzione tra CPU condivisa e dedicata non è sottolineata invano.

Per questo, questo calcolo va pensato come un controllo tecnico prima di premere il pulsante di acquisto. Se avete un sistema esistente, mettetelo accanto alle metriche reali: grafico CPU, utilizzo RAM, riempimento disco, traffico di rete in uscita, query lente, errori 5xx, tempo di attesa in coda. Se state costruendo un nuovo sistema, provate diversi scenari.

Cosa succede senza cache? Quanto cala il traffico scegliendo la CDN? Se si separa il database dallo stesso VPS, la RAM si libera? Quando il numero di worker passa da 0 a 4, dove va la CPU? Quanto ingrandisce il disco la copia di backup locale?

La scelta del pacchetto a volte nasce dalle risposte a queste domande, non da una singola riga di risultato.

Se fossi io, guarderei di nuovo soprattutto tre valori: il moltiplicatore delle ore di punta, se il database è nello stesso VPS e la copia di backup locale. Perché nella vita reale sono questi a sconvolgere di più il calcolo. Il traffico si accumula in un'ora, MySQL nella stessa macchina consuma più RAM del previsto, i backup riempiono il disco. Poi tutti si arrabbiano con il pacchetto CPU.

A volte la colpa non è della CPU.