La minchionata dei 30 secondi.

[luca.masali]

Originalmente inviato da blinking

@Luca: aridaje, con google non puoi fare ricerche avanzate come "da dentro" il forum

grazie Francesco per la modifica, speriamo che il server la regga

no, però ci fai il 90% delle ricerche che ti servono e scarichi il sistema. Poi se devi entrare nei dettagli allora è un altro discorso, quando capita vabbé, ci possono stare anche i 30 secondi.

[fai4602]

Originalmente inviato da BaroneRosso

Allora ho abbassato il time out a 10 secondi vediamo come va, un paio di anni fa ci avevamo provato e non era andato proprio bene...........................cut.

Grazie Francesco.

[foam]

mentre aspetti 30'' puoi postare di politica in off topic

[luca.masali]

Originalmente inviato da foam

mentre aspetti 30'' puoi postare di politica in off topic

eccerto, tanto lì non hai da cercare nulla, un post vale l'alro

[greg89]

Originalmente inviato da BaroneRosso

Allora ho abbassato il time out a 10 secondi vediamo come va, un paio di anni fa ci avevamo provato e non era andato proprio bene.

Riguardo il perche' e' stato messo a 30 secondi e' semplicemente un settaggio di default del forum ed e' dovuto all'enorme consumo di risorse che fa il MySql con le ricerche.
Il Mysql non e' proprio il massimo con il suo algoritmo di ricerca ed anche ottimizzando le risorse a salire delle dimensioni del DB cresce esponenzialmente il carico sul sistema (sia di CPU che di Ram), non e' una cosa che si e' inventata il sottoscritto ma un dato di fatto basta andare sul sito del VBulletin e dare una letta alla sezione forum di grosse dimensioni.
Considerate poi che la ricerca viene effettuata su un DB di oltre 4 milioni di record, mentre la tabella principale che contiene tutti i post, dove di solito e' effettuata principalmente la ricerca, e' grande circa 2.5GiB, quindi non sono proprio 4 campi da cercare. I forum piu' grandi, vedi ad esempio HWupgrade, hanno server appositi con un duplicato del DB dedicati esclusivamente alle funzioni di ricerca proprio per evitare sovraccarichi sulle macchine principali.

L'ottimizzazione si puo' certamente fare, ma per tutto c'e' un limite di risorse HW, ovviamente si possono acquistare macchine sempre piu' grosse (ed infatti e' quello che generalmente si fa) ma visto che non e' che i server non e' che li regalino dentro le uova di Pasqua si cerca di rimanere nei limiti delle proprie possibilita'
Tanto per la cronaca BaroneRosso.it gira su ben 2 server e la scorsa settimana sono stato in farm per aumentare la ram del server principale che e' stata portata a 24GB totali, visto che ultimamente avevamo finito i 12GB installati.

Per curiosità. quanto viene a costare la versione 4.0 di Vbulletin... io sarei già uno di quelli disposti a mettere qualche euro per migliorare il Barone...

[ddrake]

Originalmente inviato da BaroneRosso

Allora ho abbassato il time out a 10 secondi vediamo come va, un paio di anni fa ci avevamo provato e non era andato proprio bene.

Riguardo il perche' e' stato messo a 30 secondi e' semplicemente un settaggio di default del forum ed e' dovuto all'enorme consumo di risorse che fa il MySql con le ricerche.
Il Mysql non e' proprio il massimo con il suo algoritmo di ricerca ed anche ottimizzando le risorse a salire delle dimensioni del DB cresce esponenzialmente il carico sul sistema (sia di CPU che di Ram), non e' una cosa che si e' inventata il sottoscritto ma un dato di fatto basta andare sul sito del VBulletin e dare una letta alla sezione forum di grosse dimensioni.
Considerate poi che la ricerca viene effettuata su un DB di oltre 4 milioni di record, mentre la tabella principale che contiene tutti i post, dove di solito e' effettuata principalmente la ricerca, e' grande circa 2.5GiB, quindi non sono proprio 4 campi da cercare. I forum piu' grandi, vedi ad esempio HWupgrade, hanno server appositi con un duplicato del DB dedicati esclusivamente alle funzioni di ricerca proprio per evitare sovraccarichi sulle macchine principali.

L'ottimizzazione si puo' certamente fare, ma per tutto c'e' un limite di risorse HW, ovviamente si possono acquistare macchine sempre piu' grosse (ed infatti e' quello che generalmente si fa) ma visto che non e' che i server non e' che li regalino dentro le uova di Pasqua si cerca di rimanere nei limiti delle proprie possibilita'
Tanto per la cronaca BaroneRosso.it gira su ben 2 server e la scorsa settimana sono stato in farm per aumentare la ram del server principale che e' stata portata a 24GB totali, visto che ultimamente avevamo finito i 12GB installati.

Intanto grazie per il vostro lavoro

Spesso cali di prestazioni in MySql (ma anche negli altri dbms) sono dovuti alla progettazione del database più che alla pesantezza delle richieste. La buona notizia è che ripensando un po' la struttura si possono migliorare le cose. Il partizionamento su server di ricerca con dischi SSD è un'opzione, certo. Anche un partizionamento con discriminanti temporali avrebbe un senso.
Si potrebbe anche fare uno split delle tabelle più grandi su più dischi se non è già stato fatto. MySql ha un sistema abbastanza semplice per realizzarlo, i symlink.

Non conosco l'OS di baronerosso ma sotto Solaris c'è un'importante funzionalità di non dividere su più cilindri un file.

Non conosco in dettaglio vbulletin. Occorrerebbe anche capire come gestisca il carico di lavoro. Quante fork query faccia per una ricerca a seconda della situazione di carico del sistema. Parte dell'inefficienza potrebbe essere situata qui.

Nei nostri test eseguivamo senza problemi centinaia di query contemporanee su datawarehouse > 10gb. Server Solaris, db Oracle

Ciao!

fastidiosa è vero..
non serve a nulla perchè i 30 secondi sono proprio 30 fissi e non soggetti ad un effettivo traffico.. se paradossalmente 100 utenti fanno una ricerca e subito un'altra.. si troveranno comunque tutti insieme a rifarla dopo 30 secondi..
è chiaro che se devo aspettare 30 secondi aggiorno la pagina e appena disponibile torno ad usarla.
ne deriva che non serve come filtro per diluire le ricerche.. funzionerebbe se invece di aspettare 30 secondi ci fossero solo 30 slot libere per la ricerca e toccasse aggiornare appena se ne libera 1.. in quel caso si potrebbe dire che a causa del traffico bisogna attendere..

[BaroneRosso]

Originalmente inviato da ddrake

Intanto grazie per il vostro lavoro

Spesso cali di prestazioni in MySql (ma anche negli altri dbms) sono dovuti alla progettazione del database più che alla pesantezza delle richieste. La buona notizia è che ripensando un po' la struttura si possono migliorare le cose. Il partizionamento su server di ricerca con dischi SSD è un'opzione, certo. Anche un partizionamento con discriminanti temporali avrebbe un senso.
Si potrebbe anche fare uno split delle tabelle più grandi su più dischi se non è già stato fatto. MySql ha un sistema abbastanza semplice per realizzarlo, i symlink.

Non conosco l'OS di baronerosso ma sotto Solaris c'è un'importante funzionalità di non dividere su più cilindri un file.

Non conosco in dettaglio vbulletin. Occorrerebbe anche capire come gestisca il carico di lavoro. Quante fork query faccia per una ricerca a seconda della situazione di carico del sistema. Parte dell'inefficienza potrebbe essere situata qui.

Nei nostri test eseguivamo senza problemi centinaia di query contemporanee su datawarehouse > 10gb. Server Solaris, db Oracle

Ciao!

Senza offesa non mi puoi paragonare un ambiente open source Linux / Apache / Mysql con un Solaris / Oracle che e' un ambiente di classe enterprise che solo di licenze puo' costare diverse svariate di migliaia di euro.
Preciso nulla contro l'opensource ma sono 2 mondi completamente diversi, Solaris gira su macchine estremamente ottimizate a tale scopo e confrontare Oracle e Mysql su DB di una certa dimensione e' come andare a fare una gara di auto da corsa con una macchina a pedali, basta solo vedere che immenso casino sia avere un DB bilanciato con Mysql.
Visto che parli di query sul db ti posso dire che le stat del Mysql mi danno ben 296,30 k query l'ora, ovvero 82 e rotti al secondo su media giornaliera (bisogna pure considerare che il carico sul server ovviamente non e' mai costante lungo tutta la giornata), certo dei dischi ssd aiuterebbero non poco, ho avuto occasione di provarli, ma a parte il piccolo dettaglio che dischi del genere per server costano piu' o meno come un rene , e' ancora una tecnologia troppo recente ed ha diversi problemi sia di affidabilita' che di compatibilita', al momento preferisco i SAS a 15K che fanno egregiamente il loro lavoro.

Ottimizzare il codice ovviamente si puo' ma piu' di tanto non si puo' fare piu' che altro perche' si dipende dal progetto di altri che e' il VBulletin, piu' modifiche si applicano maggiori sono i problemi a cui si va incontro ad ogni aggiornamento, tanto per rispondere a Greg89 la licenza del VB4 e' gia' stata acquistata pero' migrare alla nuova versione e' molto complesso in quanto ci sono diverse modifiche sul sistema che obbligano a riscrivere parti di codice ed a fare diversi test per non ritrovarsi tutto bloccato (per la cronaca sul server test di casa, un semplice core 2 con 4 gb di ram, impiega circa 6 ore per fare tutti gli aggiornamenti necessari), tra l'altro il team di sviluppo ha rilasciato fin troppe versioni una dietro l'altra ed onestamente preferisco aspettare un attimo prima di fare tutto il lavoro, infatti molti grossi forum stanno passando solo ora alla nuova versione, diciamo che la mia roadmap prevede il passaggio alla nuova piattaforma durante l'estate.

[ddrake]

Infatti, non intendo comparare i due sistemi, non avrebbe senso. Anche perché i nostri erano server di tre/quattro anni fa. Surclassati da quelli attuali.
Solaris comunque lo avevamo open... anche oracle era a costo zero per la verità, in quanto partner

Quello che intendo dire è che spesso con un'ottimizzazione del db si può ottenere un vantaggio prestazionale non indifferente. Lo scopo del nostro testing era appunto quantificare il vantaggio prestazionale di una determinata soluzione.

Ciao!

[fai4602]

Ma che cavolo succede................ora di secondi me ne chiede SESSANTA !!!!!!!!!!