Entrambi le voci erano già impostate su "false".
Purtroppo le gestione di categorie e sottocategorie è stabilita a monte nei file csv che mi passano per aggiornare il catalogo.

Ho capito...

La questione dunque è di altra natura.

L' aggiornamento del csv viene fatto in tempo reale, cioè quando l' utente visualizza un prodotto o è piuttosto cadenzato?

Il modulo che gestisce quel file csv è probabile che filtri le query del tuo database, per cui si può fare ben poco a meno che non contatti chi te lo rilascia per chiedere consigli.

Memcached non lo conosco per cui mi affido alle tue considerazioni, ma consiglierei di non utilizzarlo perchè a occhio e croce fa lo stesso da filtro nell' interrogare il database. Ovviamente è un mio parere, posso anche sbagliarmi.

Avevo in mente altre operazioni da consigliarti, ma mi pare che a questo punto sia inutile.

Mi dispiace di non poterti essere di aiuto.

Ciao

@blackpanth said:

L' aggiornamento del csv viene fatto in tempo reale, cioè quando l' utente visualizza un prodotto o è piuttosto cadenzato?

Il caricamento avviene (per scelta) quando lo desidero, carico i file csv ed avvio la procedura.
Chiaramente durante questo processo il sito gira lento a causa del consumo di risorse.
Le prove di cui sopra sono state effettuate sempre mentre non vi è nessun aggiornamento ma si utilizzano i dati già presenti nel Mysql

@blackpanth said:

Il modulo che gestisce quel file csv è probabile che filtri le query del tuo database, per cui si può fare ben poco a meno che non contatti chi te lo rilascia per chiedere consigli.

Il modulo "legge" il contenuto delle righe dei csv e le scrive (applicando varie regole) nelle corrispettive query del database.

Esempio: Nel csv ho la riga "Regista" in cui abbiamo "Ridley Scott".
"Ridley Scott" sarà il contenuto scritto nella Query "regista" della tabella "prodotti".
Aprendo la pagina di dettaglio prodotto il php andrà a leggersi la query "Regista" nel mysql (associandola all'id prodotto che è univoco) e tu vedrai la voce "Ridley Scott" nell'apposita voce.

@blackpanth said:

Memcached non lo conosco per cui mi affido alle tue considerazioni, ma consiglierei di non utilizzarlo perchè a occhio e croce fa lo stesso da filtro nell' interrogare il database. Ovviamente è un mio parere, posso anche sbagliarmi.

Questo sito: ricambimotolopiccolo.it

E' realizzato sulla stessa base ma ha "solo" 5000 prodotti e meno query richiamate nella scheda articolo, infatti è sempre veloce (e si trova sullo stesso server!)

Insistevo sull'utilizzo di Memcached perchè vorrei assegnare finoa 4 Giga di Ram (degli 8 condivisi del server) al mysql SOLO per velocizzare la lettura quando serve!

Mi sembra evidente che il problema non dipende da Zen Cart, dal database o dalla banda, quindi nè dall' applicazione in uso nè dal tuo fornitore Host, ecco perchè dicevo di non poterti aiutare.

Mi pare invece che il problema sia da individuare nel modulo che gestisce il file csv e la qualità dei dati dello stesso csv.

Come dicevo nel post precedente, dovresti a questo punto chiedere consiglio a chi ti ha fornito il modulo e segnalare il problema a chi ti fornisce il csv.

Il primo per individuare eventuali bugs, il secondo per ottimizzare al meglio i dati, che effettivamente sono tanti.

Altro dettaglio da prendere in considerazione:

Un continuo, massiccio e periodico aggiornamento prodotti, produttori, prezzi, ecc... tramite csv nel database, comporta un inevitabile "imbarbarimento" dello stesso, per cui è richiesta un' altrettanta massiccia manutenzione.

A tal proposito Zen Cart in Strumenti->Gestore Negozio offre la possibilità di pulire il database da dati obsoleti, ma potresti comunque utilizzare qualsiasi altra applicazione esterna che lo faccia.

Rimango dell' opinione che con Memcached risolvi ben poco se non risolvi il problema a monte.

Infine, il paragone con l' altro sito menzionato è improponibile dato il rapporto di circa 1:8 del volume dei prodotti che si traduce in un altrettanto rapporto di 8:1 nell' amplificazione di eventuali problemi.

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...?

Con questo chiudo

ciao

@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.