Ciao,

credo che la situazione sia un pochino più complessa di come la stai immaginando. Mi spiego.

Al momento hai un server dedicato con un processore molto "entry-level" (gli Atom sono fatti per consumare poca energia e costare poco, non sono certo adatti a gestire il tipo di carico indotto da un server che deve produrre pagine dinamiche) e un discreto quantitativo di RAM. Avrai quindi due problemi durante i momenti di picco: 1) le pagine vengono servite lentamente e 2) non riesci a gestire il numero di utenti che stanno cercando di visitare il tuo sito.

Il primo problema si risolve con processori più potenti e soprattutto con l'adozione di uno stack LAMP ottimizzato (che so, Nginx + PHP-FPM + MySQL 5.5.x opportunamente tunati). Non ci dici nulla riguardo il tipo di storage che hai, ma nel caso di un forum anche la qualità dello storage incide molto sul risultato finale. Ho visto personalmente casi in cui il tempo di generazione di pagine complesse scendeva da 5-6 secondi a 500 msec dopo la migrazione da un server dedicato a una cloud con dischi ibridi.

Il secondo problema, ossia che il server non regge il numero di utenti complessivi, dipende strettamente dalla RAM e da come viene utilizzata dalle applicazioni. Ogni connessione impiega una certa quantità di risorse del sistema, per cui il numero di connessioni servibili per unità di tempo è finito e dipende essenzialmente dalla RAM del sistema. Quindi può essere che 1) 4 GB non siano sufficienti al tipo di traffico che devi reggere, oppure 2) Che il DB e lo stack applicativo (PHP, cache, web server, etc.) non siano tunati correttamente e utilizzino più RAM del necessario. Il punto è che questo problema non dipende strettamente dal processore.

Detto questo, nella scheda del prodotto che tu indichi manca proprio l'indicazione più importante: la RAM a disposizione. Non sto dicendo che sia un cattivo prodotto (non lo conosco), ma senza quell'indicazione è impossibile capire se sia adatto o meno a reggere 1 mln di pagine / mese.

Ci sono infine altre due questioni importanti da considerare:

1. quanto puoi scalare su quella piattaforma? Se il tuo traffico domani raddoppia (e te lo auguro! :D), quanto puoi "aprire i rubinetti" della RAM, etc? Puoi avere più macchine (ad es. un DB server separato) connesse alla macchina principale tramite una LAN privata ad alta velocità? Puoi incrementare il numero dei core? Quando scegli una piattaforma, è importante capire la flessibilità di crescita che hai sulla stessa, oltre al "cosa ottengo oggi".

2. l'alta disponibilità. Se si rompe qualcosa nell'hardware del server, preparati a varie ore (o giorni, a seconda del volume di dati da recuperare) di downtime. Puoi permettertelo? Con un sito che fa 1 mln / pagine mese, mi pare di no (downtime = pubblicità non servite = perdita di soldi). Dovresti quindi orientarti su una soluzione cloud ad alta disponibilità. Che vuol dire non solo un virtual server, ma anche un sistema che in caso di guasto ad un nodo provvede automaticamente a riaccenderlo su un nodo attivo, limitando il downtime a pochi secondi. Nella scheda del prodotto che hai indicato, non trovo queste caratteristiche.

La mia conclusione è che se non vuoi trovarti a "fare il nomade" tu abbia bisogno di un server cloud di taglio professionale, per un budget un po' superiore a quello che hai considerato.

My 2 cents.

Corrado Fiore

Ciao,

in questo caso, è probabile che un server dedicato lasci aperti più problemi (ridondanza, backup) di quanti ne risolva (prestazioni). Il mio consiglio è di orientarsi verso un'offerta cloud (intesa come "VPS ad alta disponibilità") che comprenda possibilmente il backup e la gestione sistemistica (monitoraggio e assistenza, magari con un team dedicato). L'alta disponibilità ti evita in buona sostanza che in caso di guasto all'hardware tu debba perdere ore o giorni a riversare dati dal backup (nota che il discorso vale anche se consideri server con dischi RAID).

Un sito come quello che tu descrivi potrebbe richiedere dai 2 ai 4 GB di RAM, posto che su Wordpress venga montato e configurato per bene il plugin W3 Total Cache e posto che MySql sia tunato correttamente. Consiglio ovviamente l'uso di PHP-FPM + Nginx al posto di Apache + mod_php.

L'audience europea, infine, è un vantaggio perché ti semplifica molto le cose: non sei obbligato ad adottare soluzioni di ridondanza geografica.

In conclusione, per rispondere alla tua domanda iniziale "[grosso provider che vende ferro e connettività] può andare bene?", penso che no, non vada bene nel senso che hai probabilmente bisogno di un altro prodotto e di una tipologia diversa di fornitore (direi un system integrator).

Mi vengono in mente alcuni nomi di system integrator che seguono progetti analoghi al tuo dal punto di vista sistemistico (vale a dire, singola applicazione PHP su cluster ad alta disponibilità): Xool.it, Alfapi.com, Goodotcom.com e Ziobuddalabs.it.

My 2 cents.

Ciao,

un po' di domande preliminari...

1. Windows o Linux?
2. Che CMS intendi usare?
3. Quanta banda prevedi di usare? E' sufficiente anche sapere cosa devono fare gli utenti (frequentare un forum è un conto, scaricare video è un altro)
4. Hai bisogno di assistenza sistemistica o fai tutto da solo?
5. Hai utenti solo in Italia o nel mondo?
6. Hai bisogno di un sistema di backup notturno? Per quanti GB di dati?
7. Hai bisogno dell'alta disponibilità? Puoi permetterti di stare fermo due giorni in caso di guasto?

In questo caso per 1) e 2) suggerirei un VPS Linux, possibilmente allocato su una cloud ad alta disponibilità in modo da non doversi preoccupare dei downtime legati all'hardware.

Da quanto scrivi mi pare che tu non abbia veramente bisogno di un pannello di controllo, quanto di un'impostazione corretta della macchina dal punto di vista sistemistico. Fatta quella, se hai un minimo di pratica con la shell, modificare i virtualhost è banale.

Per la posta, non la terrei sul VPS perché mantenere un'infrastruttura di posta è oggi dannatamente complicato se lo vuoi fare bene: non siamo più ai tempi in cui ti bastava piazzare Sendmail o Postfix, procmail e SpamAssassin per poter vendere il servizio di posta. Opterei (opinione personalissima, ovviamente) per la rivendita di caselle poggiate su un'infrastruttura ad hoc (tipo la posta di RackSpace, ad esempio).

My 2 cents
Corrado Fiore

Sorry, ho postato due volte la stessa cosa.

Ok, in questo caso tieni conto che ci sono vari limiti:

1. Configurazioni del PHP. Se usi una macchina condivisa, probabile che siano fisse e non ti sia dato permesso di modificarle nell'.htaccess.
2. Memoria del PHP. Su un hosting condiviso, raramente PHP può occupare più di 50-60 MB per processo, che possono benissimo essere insufficienti per l'upload dei file e/o il loro successivo processamento (dipende anche da come è scritta l'applicazione)
3. Limiti di tempo: PHP ha dei timer interni per limitare non solo la quantità di dati, ma anche il tempo in cui il processo rimane occupato.

The bottom line: un'applicazione del genere, con tanti processi PHP che si occupano dell'upload, non è certo adatta ad un hosting condiviso. Secondo me devi prevedere un VPS con almeno 1 o 2 GB di RAM, per un costo che varia dai 50 ai 100 Euro / mese. E devi anche affidarti ad un sistemista per il setup del tutto, ciò che vuoi fare è solo apparentemente semplice, perché all'aumentare del numero di utenti (ne bastano dieci che caricano un file) se il setup non è ben fatto il sito smetterà di funzionare per esaurimento dei thread PHP lanciabili.

Corrado Fiore

Terzo livello e sottodominio sono la stessa cosa. Il funzionamento è fatto di due elementi essenziali:

1. Una volta che acquisti il dominio qualcosa.com, tutte le zone al di sotto di .qualcosa vengono delegate al tuo DNS autoritativo. Quindi puoi crearti pippo.qualcosa.com, pluto.qualcosa.com e così via. Lo fai attraverso il servizio DNS, nel senso che il tuo DNS risponderà per ciascuna zona con l'IP del server corrispondente.

2. Quel server (macchina fisica) deve poi essere configurato a livello di web server per rispondere correttamente alle richieste entranti, quindi (semplificando) devi creare un c.d. virtualhost, che collega il nome pippo.qualcosa.com ad una specifica cartella in cui si trovano le pagine.

Ne segue che:
-- il dominio è solo uno (qualcosa.com) e paghi una volta sola la fee di registrazione (a meno che sia un dominio pseudo-geografico tipo qualcosa.milano.it).
-- una volta che hai il controllo a livello di DNS per un dominio, puoi creare tutti i sottodomini che vuoi (fintantoché puoi creare zone nel DNS).

HTH

Corrado Fiore

Perdonami, ma la domanda è posta in modo non chiaro: upload via FTP o upload via HTTP? Parti citando il primo, ma poi parli del secondo. Giusto per poterti dare una risposta sensata...

Corrado Fiore

Ciao,

benvenuto fra gli altri pignoli

Alcune domande:

1. Linux o Windows? Nel primo caso, hai pratica della shell o vorresti un pannello tuttofare?
2. Con servizio di backup? Con che rotazione? Basta 1 immagine giornaliera oppure occorre qualcosa di più?
3. Vuoi offrire anche servizi di posta elettronica...
4. ...e/o servizi di invio newsletter?
5. Vuoi esporre delle funzioni particolari del pannello ai tuoi utenti, es. potersi creare in autonomia un nuovo virtualhost, o queste richieste passerebbero da te?

Buona serata,
Corrado Fiore

La performance è il risultato di una serie di fattori. Semplificando, vuol dire che nessun anello della catena (disco, CPU, disponibilità RAM, banda, etc.) dovrebbe rallentare la produzione e la trasmissione della pagina. Sai già dove si trova nel tuo caso il collo (o i colli) di bottiglia? E' sufficiente anche una descrizione tipo "tempo di generazione della pagina PHP troppo alto" piuttosto che "trasmissione di file pesanti rallentata". Giusto per capire.

Grazie,
Corrado Fiore

Il peso della tua pagina che risulta in due valori differenti probabilmente è stato misurato senza immagini la prima volta e con le immagini la seconda.

In base agli altri dati che hai postato, secondo me ti occorre un VPS, inizialmente da 512 MB di RAM e poi da scalare verso l'alto a seconda di come crescerà il tuo traffico.

Anche avere Nginx + PHP-FPM anziché Apache httpd + mod_php ti aiuterà. Se hai molte immagini, infatti, rischi di avere molti processi httpd occupati a servire quelle. Ciascuno di essi però consumerà memoria come se stesse servendo pagine PHP, perché avranno tutti il mod_php caricato.

Corrado Fiore

Qual è l'audience del tuo sito? Italia, Europa, USA, mondo?

Ma quale sarebbe la base di iscritti totale che prevedete di avere?

Corrado Fiore

Salve lobbith,

un paio di domande:

1. dovrebbe inviarle periodicamente alla stessa base di utenti (stile newsletter) oppure una tantum (stile promozione di un evento particolare)?

2. il sistema deve essere collegato ad un sito e quindi gestire le iscrizioni / disiscrizioni?

Corrado Fiore

Ciao a tutti,

l'invio di posta massiva richiede qualcosa di più di una macchina dedicata con un servizio SMTP.

In termini di velocità, tunare bene il mail server perché sia in grado di consegnare effettivamente 200.000 email nell'arco di un giorno (suppongo tu non voglia farle arrivare con una data vecchia) non è banalissimo. Un punto di partenza può essere il classico "Tuning Sendmail for Large Mailing Lists". Vecchio, ma contiene molti consigli utili.

In termini di deliverability (la capacità di arrivare effettivamente nella inbox dei tuoi utenti, senza venire scambiato per spammer) le cose si fanno un po' più complicate. Avrai bisogno di:

1. Una classe C riservata solo a te (ci sono alcune blacklist che valutano la reputazione dell'intera classe da cui spedisci)
2. La possibilità di gestire il reverse DNS dei tuoi IP.
3. Un sistema di eliminazione automatica degli indirizzi che rimbalzano (deve essere implementato sull'applicazione). Molti provider (giustamente) ti mettono in blacklist se tenti di spedire più volte ad un indirizzo inesistente o comunque che ha provocato un rimbalzo con codice 5xx.
4. Un sistema di eliminazione "smart" degli indirizzi che rimbalzano più volte con un codice di errore temporaneo (es. una casella che è sempre piena).
5. Implementare SPF, DKIM, FBL sul tuo mail server.
6. Implementare gli header corretti nei tuoi messaggi (Sender, List-Unsubscribe, Precedence...)
7. Qualcuno che in maniera costante tenga monitorato l'andamento dei messaggi e si attivi in caso di blacklisting (nella mia esperienza, per quanto si stia attenti, capita svariate volte nell'arco dell'anno).
8. Un server web capace di sopportare il carico di picco indotto dalle immagini contenute nella newsletter o, meglio ancora, una CDN.

Secondo me, con 200.000 iscritti, che pure sono molti rispetto alla dimensione media italiana, non vale la pena di impiantare da zero tutto il sistema -- ti costa meno affidarti alle aziende che lo fanno di mestiere.

My 2 cents

Corrado Fiore

Scusate, ma se cercate una web agency non fate prima con una banalissima ricerca su Google per "web agency milano"?