Grandezza massima mysql in un forum

[Chierico80]

Quello che vi chiedo è come procedereste voi o se eventualmente aveste delle fonti a cui indirizzarmi dove potermi chiarire questo punto.

Un forum gira con l'accoppiata php-mysql su un server professionale situato in una web farm di una certa importanza, quindi l'hardware non è un problema.

Il problema è che la mole di dati tradotta in utenti, post, ricerche e navigazione in genere è decisamente esosa e il db inizia ad entrare in crisi.
Stiamo parlando di un db di circa 4 gb e gli sporadici shut down sono diventati veramente ininfluenti in termini di miglioramento.
Concettualmente quale è la strada da seguire per alleggerire il lavoro di un db così grande?
Grazie.

[filippo.toso]

Concettualmente quale è la strada da seguire per alleggerire il lavoro di un db così grande?

Puoi:

- eseguire una ottimizzazione di tutte le tabelle.
- implementare un sistema di caching sia per quello che rigurda i contenuti generati (HTML) che l'accesso al DB.
- se i contenuti del forum sono indicizzati da Google, puoi sostituire il motore di ricerca interno del forum con Google Search.
- se il traffico viene generato da bot di spammer, poi tentare di ridurre il traffico bloccando gli IP ed user agent dei bot ed implementando captcha nelle ricerche.
- puoi studiare le query, sopratutto quelle di selezione, tramite EXPLAIN per identificare se vengono utilizzati correttamente gli indici. In caso alternativo puoi ottimizzare le query aggiungendo gli indici richiesti.
- puoi implementare un cluster di server in modo da bilanciare il carico su server multipli.

Probabilmente vi sono altre soluzioni, ma al momento mi vengono in mente solo queste.

[Chierico80]

Originariamente inviato da filippo.toso
Puoi:

- eseguire una ottimizzazione di tutte le tabelle.
- implementare un sistema di caching sia per quello che rigurda i contenuti generati (HTML) che l'accesso al DB.
- se i contenuti del forum sono indicizzati da Google, puoi sostituire il motore di ricerca interno del forum con Google Search.
- se il traffico viene generato da bot di spammer, poi tentare di ridurre il traffico bloccando gli IP ed user agent dei bot ed implementando captcha nelle ricerche.
- puoi studiare le query, sopratutto quelle di selezione, tramite EXPLAIN per identificare se vengono utilizzati correttamente gli indici. In caso alternativo puoi ottimizzare le query aggiungendo gli indici richiesti.
- puoi implementare un cluster di server in modo da bilanciare il carico su server multipli.

Probabilmente vi sono altre soluzioni, ma al momento mi vengono in mente solo queste.

Grazie delle dritte, alcune sono cose a cui non avevo pensato e vedrò di mettermi sotto.
Speriamo di cavarne piede.
Grazie ancora.

[daniele_dll]

La ricerca tramite google, personalmente, non la implementerei perché non è aggiornata in tempo reale ed in aggiunta potrebbe benissimo non influire più di tanto nelle performance se la ricerca è poco usata

Il problema del sistema di caching può, come non può essere veramente utile, mi spiego meglio: la cache, in generale, viene azzerata quando si modificano i contenuti ora per esempio non ha senso sfruttare la caching per l'indice delle pagine, l'elenco dei post, gli utenti connessi e cosi via perché questi variano con un'altissima frequenza!
La cache può invece rivelarsi utili nella visualizzazione dei thread dato che la suddivisione per pagine fa si che l'unica parte variabile, principalmente con l'aggiunta di post, è l'ultima pagina dei thread quindi usando la cache in queste situazione più statiche hai un maggiore guadagno.
Per esempio se hai una pagina con i compleanni degli utenti, questa sicuramente va in cache ... e cosi via tante altre pagine che effettivamente possono trarre reale beneficio.

Perché non cachare le altre pagine? sono pagine che mutano con elevatissima frequenza con il risultato che il guadagno sulle visualizzazioni si tradurrebbe in MOLTO più lavoro dei dischi (creazione/cancellazione della cache dei file html per esempio) che andrebbe a peggiorare le performance poi di tutto il sistema. Questo punto è ovviamente aggirabile utilizzando software come memcache solo che c'è da fare un calcolo sulla memoria che gli si può assegnare dato che una volta che si riempe iniziano a far saltare le pagine con minor hits e più vecchie ... cosi se hai 250 mila thread sul forum, per fare un esempio, 50 mila utenti e cosi via ... nella realtà nella cache delle pagine html presenti su memcache ci sarà un continuo via vai perché non bastando la memoria non può tenere tutto e si ritrova comunque a rigenerare un sacco di roba

Sicuramente una configurazione ottimale sarebbe separare innanzi tutto il database dal webserver e aggiungere a questi una terza macchina per la cache delle pagine tramite memcache in modo da ridurre ancora di più il carico con le pagine php.

La macchina del backend del database e della cache dovrebberò essere rifornite di molta memoria.

Se non vuoi fare un'espansione di questo tipo, volendo puoi lasciare uniti webserver e memcache, se lo metti, e separare il backend del database in modo da ottenere comunque maggiori performance ... non so che macchine hai ma direi che avendo un database di 4gb almeno 8gb di memoria sono necessari nella macchina (se sono server di fascio medio/alta so bene quanto costa la full buffered dimm ma se vuoi ottenere qualcosa di veramente utile questo è fondamentale)

Poi come ha detto filippo, anche un eventuale cluster di tipo master/slave, od un cluster vero e proprio, andresti sicuramente ad ottenere performance ancora più elevate perché tra cache e macchine separate per la lettura delle informazioni il carico si riduce consistentemente!

Ovviamente ... se il forum non l'hai scritto tu ... ci si deve adattare a quello che può fare lui che nel caso di vbulletin ti permette sia di usare memcache sia di usare un sistema master/slave

Per finire, a tutto questo, direi di aggiungerci APC che permette il caching delle pagine php in modo da evitare di leggerle dal disco ma di eseguire quelle già convertite in bytecode in memoria in modo ridurre il carico ulteriormente. 128mb di cache ad APC sono più che sufficenti.

Oltre a questo utilizzare disci a 15 mila giri al minuto sul database è molto importante, cosi come sul web server, perché una struttura del genere sicuramente implica migliaia e migliaia di click al secondo comportando quindi migliaia e migliaia di letture dal disco

Per quanto riguarda invece il discorso dei bot, se non erro ci sono liste di ip o servizi di greylisting a cui poggiarsi direttamente tramite firewall quindi se hai un firewall hardware puoi chiedere al tuo amministratore di sistema di implementare le liste di ban per range di ip conosciuti da cui provengono bot et simili (principalmente cinesi/russi) ... anche perché non ti caricano tanto apache ma ad esempio le SSH se sono state lasciate sulla porta 22 o mysql con continui accessi se è accessibile via rete

[Chierico80]

Mi adopero immediatamente per studiare quello che hai appena detto, sono certo che ci siano ancora grossi margini di potenziamento e ottimizzazione prima di aprire nuovamente il portafogli.
Al momento grazie tante, vi terrò aggiornati con gli sviluppi.