@blackpanth said:

Come constatato da te quel sito gira tranquillamente con lo stesso Zen Cart e stesso template, sullo stesso server con 5000 articoli anche non utilizzando Memcached, quindi...?

Valuterò le tue considerazioni anche se al momento ritengo sempre che "colpa" sia sempre dell'elevato numero più che dalla "qualità" dei dati (che vengono periodicamente ottimizzati).

Se segui ancora questo thread (e il sito vedo che ha sempre gli stessi problemi), provo a darti alcuni spunti.

Innanzitutto mi risulta incomprensibile come possano esserci 40k query nella scheda prodotto.

Bisogna assolutamente partire da lì.

Hai a disposizione un ambiente di sviluppo dove fare i vari test? E' indispensabile.

La prima cosa da fare consiste nel disabilitare vari blocchi (uno alla volta) per comprendere quanto influiscono sul quantitativo di query.

Inizialmente pensavo al box delle categorie, ma questo è presente in ciascuna pagina e quindi non può essere (e la situazione diventa sempre più oscura).

Poichè capita solo con la scheda prodotto, ci si deve concentrare su quanto si trova solo qui... (scusa la banalità) ma prima di farlo, procederei con la modifica del template andando a provare quello di default (classic). Se non cambia nulla, sappiamo che non dipende da codice in override, se invece cambia, sappiamo che dobbiamo andare a guardare files in modules o templates specifici del template in uso.

Dopo queste considerazioni, in mancanza di indizi non rimane che procedere in modo 'scientifico'. Parti dal file tpl_product_info_display.php e rimuovi tutto il codice. A questo punto dovrebbe essersi ridotto enormemente il numero di queries (se così non fosse bisogna vedere cos'altro viene caricato in questa pagina e non nelle altre). Se si è ridotto, ripristini il codice, lo dividi a metà (se son 400 righe tieni solo le prime 200, 'cum granu salis' onde evitare errori di parsing) e vedi dove si trova la parte che fa esplodere le queries e così via finchè non individui il responsabile, dopodichè mi interesserebbe sapere di cosa si tratti e poi si vede come risolvere.
Ecco, non vorrei violare le regole del forum gt, ma se ne parlassimo sul forum di zen cart italia, sarebbe più utile per la comunità di Zen Cart, poi ovviamente sarebbe opportuno riportare le conclusioni anche qui.

Ti ringrazio per la risposta.
Il tempo medio si è stabilizzato sui 5-6 secondi ad articolo, sempre decisamente alto.
Per altro il sito è stato trasferito su altro server (simile) e i tempi sono rimasti sostanzialmente identici.
Sfrutterò i tuoi consigli e ti terrò aggiornato.

Quello che conta è ridurre il numero di queries nella scheda articolo, perchè anche se metti in pista una super ottimizzazione o pompi a dismisura le risorse per il db, basta poco per far andare in pappa tutto. Con 40k queries a scheda, significa che con 100 utenti hai 400k queries al secondo, una follia! Inoltre se per caso queste queries coinvolgessero qualche istruzioni di update, sei fritto. Con myisam ogni update fa un lock sulla tabella che aggiorna e quindi ogni select sulla medesima tabella viene differito al termine dell'update, capisci che con questi numeri ci vuole poco per fare un effetto leva mostruoso.

Finalmente ho avuto il tempo di iniziare dei test seri, partendo da un installazione vergine di zencart 1.5.1 (in cui sto adattando il template più le innumerevoli modifiche) (mio sito /beta) La velocità di aperturà delle pagine e sopratutto il numero di query aperte è corretta.

Chiartamente ho ancora un bel pò di lavoro da fare ma direi che la strada è giusta...:?

Nella 1.5.1 sono stati introdotti un sistema migliore di caching delle queries e una banale modifica alla scheda prodotto che rimuove una query di update ed entrambe le cose impattano positivamente sulle performances.
Io da un po' sto lavorando a varie modifiche soprattutto in merito alla costruzione del codice html + js (in ottica performance), tra cui caricamento di js a fondo pagina, con modalità analoghe a quelle che zen usa per i css (quindi i js specifici per pagina in una sola folder), spostamento delle immagini (prodotti (e a breve anche template)) su sottodominio distinto (per il discorso dei files statici su dominio diverso e senza cookies (e anche agevolare eventualmente l'uso di cdn)), deferimento del caricamento di diversi blocchi (ad esempio nella scheda prodotto i pulsanti social e vari slider di prodotti. Vedremo se ci sarà interesse da parte del team americano in queste modifiche (a me preme soprattutto quella relativa alla modifica del sistema di caricamento dei files js, perchè discretamente più strutturale rispetto alle altre, che potrebbero essere implementate anche con semplici override (beh la gestione immagini è anche lei un pochino invasiva)).

Adesso in index il sito carica solo i javascript che servono (ad esempio per lo slide), nel checkout (con fec) non carica i java dell'index ma solo quelli previsti dal modulo (tramite minify per altro) etc.
A breve farò ulteriori test con le immagini, speriamo bene....

Si, è sempre stato così, ma per sapere quali js ti porti dietro devi andare a spulciare tutte le cartelle di modules/pages e se usi un mini framework tipo jquerytools e poi lo sostituisci con altro, è un approccio con un livello di manutenibilità molto scarso, mentre se si opta per stipare tutti i js usati in giro nel sito in un unica folder (come viene fatto con i css), risulta più comodo (per non dire che si apre la strada per l'utilizzo di SASS / LESS ecc...).

@Spike00 said:

Si, è sempre stato così, ma per sapere quali js ti porti dietro devi andare a spulciare tutte le cartelle di modules/pages).

Infatti ho fatto così ed ho creato delle semplici regole in html_header.php per stabilire quali js caricare, la differenza di velocità è evidente IMHO.
Appena avrò terminato tutto ti avverto così mi darai un opinione "definitiva".

Riprendo la discussione giusto per "concluderla":
Ho terminato il nuovo sito, ho rifatto tutto da zero (su base Zencart 1.5.1 come scritto in precedenza), adesso è sempre veloce.