Forum libero

Scritto da: altg
> > > > > > ...e` un calvario.
> > > > > >
> > > > > > Pagina generata in 33025 millisecondi
> > > > >
> > > > > Pagina generata in 34 millisecondi
> > > > >
> > > > > a me va.
> > > >
> > > > Si`, ora che ha cachato tutto, va.
> > > > Riprova fra un po', quando tutti si sono scordati di pigiarla.
> > >
> > > Ecco, guarda:
> > >
> > >
> > >
> > > Possibile che solo a me lo fa?
> >
> > Se usi il link "Forum dei Troll / Principale" è più lento di solito. E` quello che stai cercando di caricare?
>
> Si`.
> Ho rilevato anche un 5mila e rotti (5 secondi) su "Sondaggi".

Sondaggi è poco usato, è sempre fuori cache.

> > > > PEr curiosita`, nel caso che un giorno succedesse a me, cos'era che causava la lentezza e come l'hai risolta?
> > >
> > > Si tratta di 4 query diverse per i casi Tutto/forum a scelta, e nascondi o meno la procura.
> > > Prima veniva eseguita la funzione di raggruppamento max su tutta la tabella, ora usa il distinct per scremare l'insieme di record su cui applicare il max.
> > >
> > > Un esempio che copre due dei quattro casi, gli altri due sono simili:
> > >

> > > SELECT MAX(id) AS mid
> > > FROM messages
> > > -- WHERE (forum IS NULL OR forum != 'Proc di Catania') -- solo se nascondi procura
> > > GROUP BY threadid
> > > ORDER BY mid DESC
> > > LIMIT ? OFFSET ?
> > > 
> > > -- diventa
> > > SELECT MAX(`id`) AS mid
> > > FROM messages JOIN (
> > >     SELECT DISTINCT `threadId`
> > >     FROM messages
> > >     -- WHERE (forum IS NULL OR forum != 'Proc di Catania')
> > >     ORDER BY `id` DESC
> > >     LIMIT ? OFFSET ?
> > > ) AS threadIds
> > > ON (threadIds.threadId = messages.threadId)
> > > GROUP BY messages.threadId
> > > ORDER BY mid DESC
> > > 

> > >
> > > Il distinct deve verificare la presenza del threadId solo nel subset scelto (nel nostro caso sono massimo 20 records) scorrendo l'indice della chiave primaria id dal basso. Sui 20 record la join tira fuori tutti gli id dei messaggi di quei 20 thread (male che va saranno 2-300 record) e su questi applica il max.
> >
> > Ah.
> > Aah.
> > Ah!
> >
> > Macche`.
> >
> > Non riesco a capire dov'e` specificato il sottoinsieme e il limite di 20.
> > Dici che potrebbe dipendere dal fatto che non capisco SQL?
> >
> > [Il che mi rende da un lato impreparato, dall'altro mi rende meno esposto al problema di sbagliare a ottimizzare una query perche` uso solo queries non ottimizzabili (perche` il filtraggio e la sua ottimizzazione non e` nella query), e mi costringe a ricorrere a espedienti piu` mirati e sicuramente piuttosto rapidi, tipo mantenere una piccola lista di tutti i thread IDs piu` aggiornati, ma questa non vuol'essere una specie di vanteria: e` solo il modo assurdo in cui funziono io.]
>
> Nel LIMIT ? OFFSET ? al posto dei punti interrogativi ci finisce 20 e il multiplo di venti che indica dove partire (0 per pagina 1, 20 per pagina 2...)

AH! Ora e` chiaro, pensavo che il punto interrogativo facesse parte di una qualche strana sintassi che li ereditava da non-so-dove.

> Hai un modo di funzionare poco scalabile.

Si`, e` un modo di funzionare molto incentrato sul "qui e ora", una specie di adattamento evolutivo ultraspecializzato del prodotto, di quelli che poi portano alle estinzioni di massa quando cambia qualcosa.

Quando cambia qualcosa, magari riscrivo tutto.
Non so dire se sia meglio o peggio.
Meno produttivo di certo.

> Sql è un linguaggio terribile, l'explain di mysql è praticamente inutile.

Tanto non l'ho mai davvero usato. La storia completa e` che, quando scrissi il mio forum engine, iniziai con un server che non aveva un DBMS e poteva usare solo files, che pero` tendevano a essere poco thread-safe e venivano a volte disturbati da processi di backup in cron. Quando sullo stesso host arrivo` la possibilita` di usare SQL, passai a SQL per risolvere quei problemi, ma mi piacque mantenere la possibilita` di tornare allo storage in flat file. Sicche` ando` a finire che usai SQL come semplice surrogato di file system.

Anche per il fascino di fare una cosa strana.

> Io mi sono `formato` usando l'explain di oracle, esaustivo e decisamente completo.
> Tuttavia se riesci a far lavorare il dbms per te, è tutto di guadagnato. Più cose fa lui, meno ne fai te.
> Considera pure che più dati devono transitare tra db e applicazione e più sarai lento.
> Fosse per me, si usarebbero solo stored procedures per tutto: 0 possibilità di sql injection, massime performances perché non devi far viaggiare degli stringoni - le query - tra applicazione e db e farli ri-parsare dall'ottimizzatore del dbms, oppure farle hashare per cercare nella cache delle query frequenti...

Cioe` ti appoggi interamente al DBMS. Io prima di appoggiarmi a qualcosa, tendo a voler essere sicuro che quel qualcosa sia persistente nel tempo, anche se poi il mio scartare certe cose dipende in gran parte da quando quelle cose sono state introdotte al grande pubblico (fra cui a me): se troppo tardi, tendo a non adottarle o ad adottarle con mooolto ritardo. Forse e` un mio adattamento evolutivo alla sparizione dei sistemini su cui lavoravo un tempo. Oggi il mondo tende ad essere piu` costante e standardizzato, e penso che se avessi cominciato oggi sarei molto meno diffidente dalle componenti che non sono sotto il mio diretto controllo.