Forum e dietro le quinte: facciamo chiarezza

[Paolo Corsini]

Buongiorno a tutti;

ho chiuso le altre discussioni sul motore di ricerca in quanto vorrei con questa fare il punto preciso della situazione, cercare di spiegarvi che cosa è stato fatto in queste settimane e se possibile chiarire i dubbi che sono stati evidenziati in molti post.

Non annuncio da ora una data di apertura del motore di ricerca, ma stando alle previsioni di ricostruzione che abbiamo fatto questa mattina l'operazione dovrebbe essere conclusa per Lunedì mattina. Se ci sarà un ritardo credo sarà questione di qualche ora, massimo 1 giorno, e solo perché lo script di ricostruzione avrà impiegato più del previsto.

E' una discussione lunga: prendete un po' di pop corn e leggetevela con calma, cercando di non farvi venire mal di testa. A me è venuto a scriverla, quindi non preannuncio nulla di buono.


Una fotografia del forum

Il forum di discussione di Hardware Upgrade è on line da Luglio 1999; sono ormai quasi 4 anni. In questo periodo sono stati pubblicati oltre 4,7 milioni di messaggi, in poco più di 427.000 discussioni. Si tratta di un quantitativo di messaggi elevatissimo, che è impossibile tenere memorizzato con pressoché qualsiasi tipo di software per forum esistente in commercio.

Ovviamente, scrivendo un sistema custom pensato per gestire una mole di mesaggi così elevata il problema sarebbe evitabile. Ovviamente questo genera costi, sia di tempo che economici, che a mio avviso sono sia troppo elevati, sia inutili.
Per questo motivo, non solo su hwupgrade ma in qualsiasi forum che abbia raggiunto dimensioni elevate, si è sempre provveduto a cancellare parte delle discussioni vecchie quando il loro numero è diventato troppo elevato.

Il problema

Le discussioni e qualsiasi informazione pubblicata in un forum è memorizzata in un database, nel nostro caso MySQL. I post, i dati degli utenti e qualsiasi informazione è pertanto archiviata in tabelle del database, secondo la struttura utilizzata da ogni specifico software di funzionamento (phpbb, vbulletin o quello che volete).

Più dati sono inseriti, più grande sarà il database.
A parità di dimensioni del database, più utenti richiedono in uno specifico momento informazioni e più carico verrà generato sul server.
Al crescere del numero di informazioni memorizzate, più aumenta il numero di utenti contemporaneamente alla ricerca di dati e maggiore sarà il carico.

Facciamo un esempio che spero renda l'idea:

"Il database del forum è una libreria, i libri in essa contenuti sono i messaggi e gli utenti del forum sono persone che cercano un libro. Se il n° di libri aumenta ricercare nella libreria sarà più difficile. Se io sono un utente che deve cercare un libro e davanti a me ho una coda di altro 100 utenti in attesa, perderò più tempo.
Il carico complessivo sul database è dato da quanto tempo ci vuole, per ogni utente, a trovare il proprio libro. Maggiore è il n° di libri disponibili, e maggiore il n° di utenti in coda, più elevato sarà il tempo che mi ci vuole a finire la ricerca del mio libro e quindi maggiore sarà il carico."

Negli ultimi mesi ci siamo trovati a gestire un database sempre più grande, e con un numero di utenti contemporaneamente connessi sempre molto elevato. Lasciate perdere il record di n° massimo di utenti collegati: quello che crea problema al database è soprattutto un n° di utenti connesso contemporaneamente al database per un lasso di tempo lungo. Nel corso della giornata siamo molte ore oltre i 500 utenti contemporanei.

Il motore di ricerca è, nella struttura del database, l'elemento che più di tutti genera carico. Cerco di spiegare in modo molto semplice come questo funziona.

Ci sono 2 tabelle fondamentali
- phpbb_search_wordlist: elenco delle parole che possono essere oggetto di una ricerca;
- phpbb_search_wordmatch: corrispondenza tra le parole elencate nella tabella precedente e discussioni nelle quali queste parole sono presenti.

La prima tabella è discretamente grande ma comunque ha limiti; il termine "gatto", ad esempio, vi è compreso solo una volta. La seconda è mostruosamente grande.
La tabella dei messaggi, cioè quella che contiene tutti i post scritti, memorizza un messaggio per ogni riga della tabella. Con 2 milioni di messaggi, pertanto, quella tabella avrà 2 milioni di righe, che sono tante.

Di tutte le tabelle presenti nel database quella phpbb_search_wordmatch è in assoluto la più grande. Per rendere l'idea, nei giorni scorsi siamo arrivati a farle raggiungere il valore di 35 milioni di righe, indicizzando 1 milione di messaggi. Una tabella di questo tipo ha dimensioni così elevate che il database complessivamente non può essere caricato per intero nella memoria di sistema; di conseguenza letture e scritture vengono fatte sui dischi, che ovviamente hanno velocità pari a una frazione di quelle della memoria di sistema.
Il server, quindi, è carico e l'effetto finale è che gli utenti si lamentano
"il forum è lento, non va".
Mettere dischi più veloci e aumentare la memoria risolve solo in minima parte il rpbolema: il database comunque giorno dopo giorno continua a crescere.

Questo spiega perchè, nel momento in cui ci sono problemi di carico, la prima cosa che si fa è chiudere il motore di ricerca: quella tabella di dimensioni mostruose non viene più toccata, e il server "respira".

Lo status attuale

Per cercare di mantenere elevate le prestazioni velocistiche del forum, fornendo un servizio valido e allo stesso tempo non passando tutta la giornata a controllare il carico del forum, si è reso necessario raggiungere un compromesso. Evitare di avere troppi messaggi memorizzati e allo stesso tempo contenere il più possibile le dimensioni della tabella phpbb_search_wordmatch, ovviamente facendo in modo che le ricerche funzionino correttamente quindi forniscano risultati validi.

Nell'ultimo mese e mezzo abbiamo cercato di capire come poter arrivare a garantire questo risultato. Il primo passo da fare era chiudere il motore di ricerca, riaprendolo solo quando avremmo risolto tutto.

In questi 45 giorni abbiamo proceduto in questo modo:
- sfoltito il n° di messaggi memorizzati, passando da 2,1 milioni a circa 1 milione (valore attuale);
- smanettato parecchio dal lato server, ottimizzando mysql e scoprendo sul campo come poter gestire al meglio la configurazione del database. MySQL è un sistema molto interessante ma richiede anche molti test sui timings per arrivare a sfruttarlo al meglio.
- studiato il codice del motore di ricerca, cercando di fare in modo che la tabella di ricerca avesse dimensioni le più piccole possibili, non perdendo però significatività nei risultati ottenuti.

Abbiamo chiuso tutti questi punti e da 48 ore circa stiamo ricostruendo il motore di ricerca. Finita questa operazione, per l'ultima volta, il search verrà riaperto e potremo finalmente considerare chiuso questo lavoro.

Perché ci state mettendo così tanto tempo?

Semplice: perché non esiste un "how to" per ottimizzare database di forum di queste dimensioni. La risposta che tutti i programmatori di forum danno quando si dice loro che si hanno problemi di carico eccessivo è:
"potenzia il tuo hardware";
quando fai presente che quello che c'era da ottimizzare dal lato mysql è stato fatto, e che l'hardware è quanto di meglio puoi usare, la risposta è unica:
"cancella i messaggi, riduci la dimensione del tuo database".

Abbiamo seguito una strada molto più lunga, quella di sperimentare (non senza errori) e di capire come ottimizzare direttamente per mantenere un elevato numero di messaggi memorizzati, fornire una ricerca funzionante e valida e soprattutto far fronte alla futura crescita nel numero di utenti contemporaneamente connessi al forum.

Per arrivare a questo abbiamo dovuto lavorare parecchio, imparando molte cose nuove, sperimentando, sbagliando, tornando al punto di partenza dopo 2 settimane di lavoro perché ci si è accorti che quanto fatto nel frattempo non permetteva di risolvere la situazione.

Oltretutto, alcune delle operazioni richiedono molto tempo per poter essere completate. Giusto per citarne una, la ricostruzione del motore di ricerca con "soli" 500.000 messaggi richiede circa 48 ore di tempo macchina.

Di certo non ci abbiamo messo così tanto per puro spirito masochistico.


I post importanti che sono stati persi

Ci sono stati degli errori non voluti nella fase di cancellazione dei messaggi. Una volta che avremo finito di ripristinare il motore di ricerca cercheremo di ricuperare le discussioni più importanti che sono andate accidentalmente perse e le renderemo nuovamente disponibili.
Per cortesia non scriveteci ora quali sono, lo sappiamo e una volta finito con il search ci occuperemo anche di questa cosa.

Perché phpbb e non vbulletin?

Lo scorso mese di Novembre, dopo esserci resi conto che il forum stava crescendo troppo rapidamente e che il database aveva forti colli di bottiglia, abbiamo iniziato a valutare una soluzione alternativa a vbulletin. In quel periodo si era in attesa d'informazioni sulla versione 3 di vbulletin, nella speranza che venissero introdotte varie modifiche dal lato codice a noi utili per gestire carichi elevati.

Purtroppo abbiamo scoperto che vbulletin 3, che beninteso è ancora in fase di beta testing non pubblica in questo momento, non solo non avrebbe integrato le ottimizzazioni che speravamo di vedere, ma avrebbe probabilmente appesantito ulteriormente il carico sul database in quanto integra una gestione dei thread, dal lato grafico, che presumibilmente fa fare al sistema molte più queries al database. Parlo per supposizioni vedendo le beta di vbulletin 3, il codice non l'ho mai potuto vedere.

In particolare, il limite non arginabile di vbulletin è stato il supporto alle sole tabelle MyISAM di MySQL. Stante il numero di utenti contemporaneamente sul forum, il numero di messaggi e il quantitativo di richieste al secondo fatte al server database era per noi indispensabile passare alle tabelle Innodb, che ci avrebbero permesso di gestire nel modo migliore questa mole di carico.
Vado volutamente in modo molto sintetico, non mi sembra il caso di annoiare con spiegazioni tecniche anche perchè ci tengo a far capire che uno degli elementi base fosse la possibilità di utilizzare le tabelle innodb al posto di quelle MyISAM

Vbulletin non permetteva questo, mentre phpbb si. Abbiamo fatto alcuni test qui in redazione ad inizio Dicembre scoprendo che a parità di dati memorizzati e di utenti contemporaneamente sul forum, il carico generato da phpbb era sensibilmente inferiore a quello di vbulletin, grazie soprattutto all'utilizzo delle tabelle innodb (ma non solo quello).

Per questo motivo siamo pasati a phpbb, soluzione che dal punto di vista della fruibilità lato utente è peggiore di vbulletin (la prossima versione 2.2 dovrebbe migliorare di parecchio le cose) ma che ci ha permesso di risolvere molti problemi dal lato database.

Se e quando sarà disponinibile un software più efficace saremo ben contenti di provarlo e, se il caso, di adottarlo in produzione. Al momento attuale, pur con i tanti limiti, phpbb ci pare la soluzione che meglio di tutte fa fronte al traffico che generiamo.

Ora legale - solare

Mi quoto da un'altra discussione:

Originally posted by "Paolo Corsini"

Allora, stamattina abbiamo studiato un po' di elementi di phpbb. Il codice, per come è statos critto, fa sempre riferimento all'ora solare GMT (Greenwich Mean Time). Attualmente, essendo noi in italia econ ora legale, siamo a 2 ore in più rispetto all'orario GMT

Preso dalla documentazione di phpbb:

"phpBB 2.0.x does not in any way support daylight savings time. All times are based from GMT (Greenwich Mean Time) which is fixed throughout the year. "

Conclusione: se vi sloggate vedrete che l'ora riportata è quella corretta. Se restate loggati nel vostro profilo avete impostato come roario
GMT+1.

Cliccate qui:

http://forum.hwupgrade.it/profile.php?mode=editprofile

e andate a modificare il vostro profilo mettendo
GMT+2
e l'ora sarà a posto.

Ovviamente con questo gli orari dei server non c'entrano nulla: quelli si erano già sistemati da soli ieri.
Stiamo verificando se sia possibile, senza dannare troppo con il codice, modificare questa impostazione in modo differente

Ma perché non chiedete il mio aiuto? Sono bravo in...

Molti utenti si sono domandati perché non abbiamo chiesto aiuto a loro. Ci sono molti programmatori e professionisti che leggono queste pagine.

La risposta è semplice: nessuno di voi conosce questo software, o meglio l'ha mai usato con le condizioni di carico che abbiamo noi. In realtà credo che non ci sia in uso un forum "motorizzato" phpbb che abbia il nostro volume di traffico.
Oltretutto, nessuno da fuori ha accesso ai nostri server e quindi sa come questi rispondano al carico.

Perdonatemi l'esempio forse stupido, ma qualora fossi anche il più bravo pilota di automobili al mondo non potrei pretendere di sapere tutto sulla guida moticlistica, teoria e pratica. Magari sono una persona così brava da eccellere in entrambe le cose, ma non credo molto nelle eccezioni.
Detto in altro modo: se sei un bravissimo sys admin in ambiente Oracle magari t'invidio pure, ma non è detto che la tua conoscenza possa applicarsi alla gestione del database di un forum di discussione.

Con tanta sincerità, in queste settimane avrei preferito di gran lunga dare in mano questa "patata bollente" a qualcun altro, guadagnando così tempo e dedicandomi a tutt'altro. Non è stato fatto soprattutto perché non c'è nessuno che abbia questo tipo di competenza sul campo con le condizioni che ci troviamo ad affrontare.
Beninteso, non lo ero neppure io. Ora, dopo 1 mese di testa picchiata contro il muro, forse sono un po' meno ignorante di prima in questo campo.

[alex10]

Grazie per la spiegazione e grazie per esserti spaccato la testa per fornirci questo modo di parlare, discutere, incazzarci e divertirci assieme a tante persone.
Ciao e buon lavoro

[jumbo81]

bè
bella spiegazione
esauriente
deve comunque dare molte più soddisfazioni una soluzione di questo genere, nata dalle vostre idee e ragionamenti
che una soluzione "taglio 3 milioni di msg e ne tengo sempre 300 mila al massimo, così sono a posto"

a questo punto....

[/siz]

buon proseguimento!

[pnx]

Ci voleva proprio!

Complimenti.

[pinball]

Già ora è tutto + chiaro il perchè il motore non vada da così tanto tempo...

ciao e buon lavoro

PS: sei disponibilissimo

[pinball]

ma sbaglio o non è possibile modificare + i post? e' opera che mi crea casini o è prorpio così?

[Paolo Corsini]

Originally posted by "moly82"

ma sbaglio o non è possibile modificare + i post? e' opera che mi crea casini o è prorpio così?

Non su questo forum, ma per un parametro che aveo configurato male.
Da adesso si può, modificare ma non aprire

[pnx]

Originally posted by "Paolo Corsini"


Non su questo forum, ma per un parametro che aveo configurato male.
Da adesso si può, modificare ma non aprire

A me risulta ancora disabilitata la modifica dei post...

[pnx]

Originally posted by "pnx"



A me risulta ancora disabilitata la modifica dei post...

Come non detto, dopo il post è magicamente apparso il tastino.

[allmaster]

quindi i nuovi emoticons sono ispirati al problema del motore di ricerca....

il database che cresce

il povero Paolo che ce la mette tutta

l'utente senza motore di ricerca

ig: gli errori in generale.

[Maestro]

Lo so magari è inutile.. non ho mai avuto dBs di queste mostruoso dimensioni.. ma hai gia' provato invece di usare il search del phpBB di crearne uno semplice che faccia una query generica senza usare le 2 tabelle? Lo sta facendo il wm di un forum in cui sono mod con ottimo risultati = migliori risultati della ricerca, canc delle 2 tabelle del dB che occupavano metà spazio e più velocità anche durante l'invio dei posts che era lento per via delle creazione delle chiavi nelle tabelle..

Magari sono stato inutile ma la mia l'ho detta..

Ciao, fammi sapere

[sk8ne]

ma come motore di ricerca provvisorio non è possibile utilizzare il servizio di google? Il sito di unitn.it lo usa e funziona decentemente... pittosto di essere senza....

ecco il link:

http://www.google.it/custom?domains=hwupgrade.it&sitesearch=hwupgrade.it

provate a vedere se e come funziona...

[Paolo Corsini]

Originally posted by "Maestro"

Lo so magari è inutile.. non ho mai avuto dBs di queste mostruoso dimensioni.. ma hai gia' provato invece di usare il search del phpBB di crearne uno semplice che faccia una query generica senza usare le 2 tabelle? Lo sta facendo il wm di un forum in cui sono mod con ottimo risultati = migliori risultati della ricerca, canc delle 2 tabelle del dB che occupavano metà spazio e più velocità anche durante l'invio dei posts che era lento per via delle creazione delle chiavi nelle tabelle..

Magari sono stato inutile ma la mia l'ho detta..

Ciao, fammi sapere

Ciao,
a parte che scrivere codice e provarlo ci si metterebbe comunque più tempo, l'approccio di phpbb è buono in se e per se quindi non penso sia da ripensare, almeno per il momento.

I problemi nascono, ma nascerebbero comunque, quando hai una mole di post elevatissima e tanti termini che possono essere indicizzati.

Stamattina abbiamo finito la simulazione di ricostruzione qui in redazione, con un dump del database di circa 2 settimane fa e una mole di messaggi pari a quella che avrà il forum alla fine di tutto.
Le parole indicizzate, quindi ricercabili, sono poco meno di mezzo milione (escludendo ovviamente i termini con solo 2 lettere); il n° di risultati complessivi presenti nella tabella è di circa 8 milioni. Questo grazie al tweaking spinto che abbiamo fatto, viceversa sarebbero stati circa 36 milioni.

Ora, i milioni di risultati persi sono quelli non utili alla frubilità del motore di ricerca, quindi le ricerche che verranno effettuate saranno comunque corrette ed efficaci. Gestire una tabella di 8 milioni di record è comunque un bel macello, ma molto meglio di una da 36

[Quincy_it]

Innanzitutto grazie Paolo per la spiegazione esauriente che hai scritto (deve essere stata una faticaccia solo quella, figuriamoci tutto il discorso del Motore di Ricerca).
Visto che ormai dovremmo (sgrat sgrat ) essere in dirittura d'arrivo non resta che dire: In bocca al lupo!

[sinadex]

ok sei stato chiarissimo, solo vorrei conferma di una cosa: la tabella delle parole indicizzate è usata perchè è improponibile fare una search nel db principale (quella da 1 milione di post)?

[Paolo Corsini]

Originally posted by "sinadex"

ok sei stato chiarissimo, solo vorrei conferma di una cosa: la tabella delle parole indicizzate è usata perchè è improponibile fare una search nel db principale (quella da 1 milione di post)?

No, perché phpbb è fatto in questo modo. Fare delle ricerche full text in quelle tabelle sarebbe da pazzi in termini di carico

[alexrena]

quindi il metodo dell' ipb sarebbe fallimentare in un forum molto grande?

[Paolo Corsini]

Originally posted by "alexrena"

quindi il metodo dell' ipb sarebbe fallimentare in un forum molto grande?

Con le conoscenze che ho non te lo posso dire con certezza.
Certo è che la tabella post è già grandicella di suo e viene letta e scritta molte volte al secondo; far gravare su questa anche tutte le queries di ricerca vorrebbe dire farle fare kaput in pochi minuti.
Ovviamente con questo traffico; in soluzioni molto più leggere questo potrebbe portare anche a boost prestazionali.

Un po' come le persistent connections al database: con poco carico vanno benissimo, velocizzano ulteriormente. Ma con un carico che inizia a crescere, e quindi a valori molto più bassi di quello che abbiamo noi, generano un carico tremendo sui server e portano ad effetti auto attacco DOS che hanno conseguenze poco piacevoli, per chi deve amministrare.

[axel70]

grazie grazie e ancora grazie per tutto quello che fate per noi !

dopo tutto questo lavoro vorrei proporre paolo per la beatificazione

[FreeMan]

Originally posted by "pnx"



A me risulta ancora disabilitata la modifica dei post...

anche a me

edit: apparso anche a me dopo il post..

>bYeZ<