Numero di query per pagina, pareri

[Uno]

Che ne dite?
Leggo che un wordpress può arrivare anche a 35/40 (o forse più) , un vbulletin senza mod si assesta su una dozzina all'incirca.....
Io "mi sto facendo" delle paranoie per cercare di contenere le query su una mia applicazione, ma tutto sommato 10/15 (ad esagerare) potrebbero essere accettabili, soprattutto se pulite senza tanti giri e ramificazioni.

[andrea.paiola]

scusa ma dipende anche che tipo di query file e su che mole di dati

[Uno]

Da un parte hai ragione pure tu, messo così è troppo generalista questo post.

Pensavo di aprire l'argomento per fare un pò il punto della situazione. Tutto sommato il tema è la progettazione e la programmazione ma è utile ed interessante anche dal punto di vista server/risorse etc....
Ci sono troppe applicazioni mal progettate in giro, applicazioni che spesso per moda diventano anche frequentemente usate.

[FlameNetworks]

@Uno: tieni presente che, qualora non lo sapessi già, l'utilizzo di select count(*) è il modo peggiore di scrivere una query e che dovrebbe essere utilizzato con molta parsimonia.

Ciao,

Fabrizio

[fantomas]

La homepage di un wordpress stile magazine con tanti plugin può superare le 100 queries.
Solo che come hanno già detto, il peso sul server dipende dal tipo di query.
Ho visto dei plugin che fanno queries con svariate join che ritornano decine di migliaia di record: una query di quelle vale più di un centinaio fatte bene su campi indicizzati.

[Uno]

Scusatemi non riesco ad esprimere il senso che volevo dare a questo 3d..... magari non ce l'ha

[andrea.paiola]

Scusatemi non riesco ad esprimere il senso che volevo dare a questo 3d..... magari non ce l'ha

e meno male che sei mod

[Uno]

Ma che discorsi sono?
Non sono laureato in scienze della comunicazione, ammesso e concesso che serva in tal senso.
Per me aveva un senso, ma non riesco a trasmetterlo, mod o no....

[2busy]

Nell'immagine in allegato c'è il numero di query della home di un carrello in zend chart.
A pelle sembra essere veloce uguale come un blog wordpress medio.
Effettivamente (se quel numero è vero) sembra che anche un elevato numero di query ben strutturate sia più facilmente gestibile di un unico megajoin ad minchiam che restituisce tutti i valori del db ad ogni esecuzione...

[Valeriano Manassero]

Se invece di guardare a piccole applicazioncine in cui l'ottimizzazione è spesso lasciata la caso, provassimo a dare un'occhiata a qualche architettura su tre livelli seria, ci renderemmo conto che il numero di query è, spesso, la variabile meno significativa.
Un buon middle-object dovrebbe essere in grado di fare caching in modo opportuno. Se a questo ci aggiungiamo una buona conception del database, soprattutto a livello strutturale, con le macchine odierne faremo molto prima a mettere in ginocchio la banda che non il database stesso.

Naturalmente sono considerazioni generiche, poi l'eccezione scappa sempre eh...

[guest]

Naturalmente sono considerazioni generiche, poi l'eccezione scappa sempre eh...

Non puoi tutelarti con un try/catch?

Ok vado via.

[Kuro]

Non puoi tutelarti con un try/catch?

Ok vado via.

no, se usi php4

Ok, vengo via con te

[Uno]

Nell'immagine in allegato c'è il numero di query della home di un carrello in zend chart.
A pelle sembra essere veloce uguale come un blog wordpress medio.
Effettivamente (se quel numero è vero) sembra che anche un elevato numero di query ben strutturate sia più facilmente gestibile di un unico megajoin ad minchiam che restituisce tutti i valori del db ad ogni esecuzione...

692?
Non riesco neanche con tutta la buona volontà a capire come è possibile su una sola pagina fare un numero di query simile.
Comunque certo è vero in certi casi che un numero maggiore di query micronizzate è sicuramente più performante di enormi query monolitiche, però in entrambi i casi la riduzione comunque dovrebbe dare velocità all'applicazione. Soprattutto se parliamo di grandi numeri, perchè ovviamente se parliamo di un blog anche da 2/3000 accessi al giorno, pure se c'è un omino che scrive i testi volta per volta il sito funziona

Se invece di guardare a piccole applicazioncine in cui l'ottimizzazione è spesso lasciata la caso, provassimo a dare un'occhiata a qualche architettura su tre livelli seria, ci renderemmo conto che il numero di query è, spesso, la variabile meno significativa.
Un buon middle-object dovrebbe essere in grado di fare caching in modo opportuno. Se a questo ci aggiungiamo una buona conception del database, soprattutto a livello strutturale, con le macchine odierne faremo molto prima a mettere in ginocchio la banda che non il database stesso.

Naturalmente sono considerazioni generiche, poi l'eccezione scappa sempre eh...

Ecco, non siamo completamente d'accordo, ma un pò hai capito di che volevo parlare...
Ho iniziato dalle query perchè in questi giorni sto lavorando sulla struttura da dare al db del mio progetto però è ovvio che la cosa non può limitarsi a queste ma non le ritengo meno importanti o da veder dopo di un buon caching.
Se un sito è relativamente statico, cioè dinamico ma aggiornato non minuto per minuto, potrei anche mettere su un db a casaccio e poi con la cachè sistemare tutto, un blog, commenti a parte potrebbe essere un esempio ideale, uno inserisce qualche post al giorno nella migliore delle ipotesi, la cachè sforna tra un aggiornamento ed un'altro sempre la stessa pappa.
Però un forum, un sistema di commenti, un sistema di inserimento contenuti piuttosto articolato di tipo sociale non funzionerà mai bene così.
Si volendo si fa... ma perchè non studiare le cose meglio fin dal principio?
Prendiamo un forum per esempio
Uno scrive un post e quel post (con tutti i dati che si porta dietro) deve apparire minimo nella sua categoria e sulla pagina principale del forum (eventualmente anche su altre pagine del sito)
Quindi se uso cachè su un forum ogni volta che uno aggiunge un post devo ricreare la cachè di almeno 2/3 pagine. Se è un forum un pò trafficato con parecchi post nuovi, cioè con un post ogni tot minuti non conviene neanche più mettere in cachè (si può fare, ma non ha senso). Ma allora è fondamentale che le query per ognuna di queste 2/3 pagine sia più leggera possibile.

Per allargare il discorso una buona applicazione deve stare attenta anche a come gestire le variabili, gli array etc...

[Valeriano Manassero]

692?
Non riesco neanche con tutta la buona volontà a capire come è possibile su una sola pagina fare un numero di query simile.
Comunque certo è vero in certi casi che un numero maggiore di query micronizzate è sicuramente più performante di enormi query monolitiche, però in entrambi i casi la riduzione comunque dovrebbe dare velocità all'applicazione. Soprattutto se parliamo di grandi numeri, perchè ovviamente se parliamo di un blog anche da 2/3000 accessi al giorno, pure se c'è un omino che scrive i testi volta per volta il sito funziona



Ecco, non siamo completamente d'accordo, ma un pò hai capito di che volevo parlare...
Ho iniziato dalle query perchè in questi giorni sto lavorando sulla struttura da dare al db del mio progetto però è ovvio che la cosa non può limitarsi a queste ma non le ritengo meno importanti o da veder dopo di un buon caching.
Se un sito è relativamente statico, cioè dinamico ma aggiornato non minuto per minuto, potrei anche mettere su un db a casaccio e poi con la cachè sistemare tutto, un blog, commenti a parte potrebbe essere un esempio ideale, uno inserisce qualche post al giorno nella migliore delle ipotesi, la cachè sforna tra un aggiornamento ed un'altro sempre la stessa pappa.
Però un forum, un sistema di commenti, un sistema di inserimento contenuti piuttosto articolato di tipo sociale non funzionerà mai bene così.
Si volendo si fa... ma perchè non studiare le cose meglio fin dal principio?
Prendiamo un forum per esempio
Uno scrive un post e quel post (con tutti i dati che si porta dietro) deve apparire minimo nella sua categoria e sulla pagina principale del forum (eventualmente anche su altre pagine del sito)
Quindi se uso cachè su un forum ogni volta che uno aggiunge un post devo ricreare la cachè di almeno 2/3 pagine. Se è un forum un pò trafficato con parecchi post nuovi, cioè con un post ogni tot minuti non conviene neanche più mettere in cachè (si può fare, ma non ha senso). Ma allora è fondamentale che le query per ognuna di queste 2/3 pagine sia più leggera possibile.

Per allargare il discorso una buona applicazione deve stare attenta anche a come gestire le variabili, gli array etc...

Emh, io cambierei approccio totalmente, stamattina non ho tempo, oggi se ce la fo ti metto giù due righe su come affronterei una robina così...

P.S.
Non do seguito alle battut sul try/catch se no smerdo il thread (quando comincio sono peggio di voi).

[andrea.paiola]

beh è comunque anche vero che un mysql configurato correttamente ( cache & co. ) e che ha risorse adeguate a disposizione, ha comunque le query in ram

se abbiamo un'astrazione del db tipo ActiveRecord, quindi ad un oggetto corrisponde una tabella, si possono certo pensare cache intermedie ( esempio a caso http://railsenvy.com/2007/3/20/ruby-...erecordcaching )... magari usare memcached & co.

o per esempio guarda come è in NHibernate http://www.castleproject.org/activer...evelCache.html


insomma usa un layer di astrazione dal db e scegli le politiche di caching che ti servono... nel mio framework php l'oggetto cache può anche lavorare sulle query ( può skippare qualsiasi frammento di codice php )