Il sito è: gamesmart.it

memcached dovrebbe servire per aumentare la velocità di lettura delle query mysql nel momento in cui si apre una qualunque scheda articolo.
Grazie per l'attenzione.

Ciao

Complimenti per il sito.
Effettivamente l' apertura del sito è veloce ma come dici tu, quella delle pagine prodotto è lenta.
Le immagini inoltre non sono pesanti.

Ci sono molte variabili da prendere in considerazione...

La prima operazione che dovresti fare è quella di interrogare i tempi di risposta delle query.

Zen Cart ha lo strumento Parse Time che trovi da settare in Configurazione-> Connessioni-> Visualizza Page Parse Time da impostare su "true". Il rapporto verrà visualizzato nel footer del sito.

Esempio rapporto:
Parse Time: 20.623 -
Number of Queries: 1958 -
Query Time: 10.548885139802

Adesso dovresti interpretare le cifre:

Se il Parse Time è troppo grande e il Query Time è piccolo significa che molti utenti sono collegati nello stesso momento al tuo server.

Se il Parse Time e il Query Time sono entrambi molto grandi, vuol dire che ci sono problemi con le prestazioni del database.

Stessa cosa qualora il Parse Time e il Query Time hanno più o meno la stessa cifra ma con un tempo superiore ai 2 - 3 secondi.

Dopo questa operazione consiglierei, di provare a settare da admin sul template di default classic per confrontare i tempi di reazione, per vedere se il problema è quello.

Se non noti sostanziali cambiamenti, in questi caso dovresti aprire un ticket e far presente il tuo problema, di banda o prestazioni del database, al tuo Host fornitore di servizi per potenziare il tutto.

Ci sarebbero altre cose... te le dirò magari dopo...

Ti ringrazio, ho riabilitato il parse time, alcuni esempi con il Template Predefinito:

Home Page

Parse Time: 3.139 - Number of Queries: 753 - Query Time: 1.67746045444

Un Prodotto Qualunque

Parse Time: 19.458 - Number of Queries: 43523 - Query Time: 3.53864920786

Altri template sono stati eliminati (incluso il "Classic") principalmente a causa delle pesanti modifiche apportate (come avrai notato dello Zencart "base", 1.3.9h è rimasto "poco")
Con il mio fornitore di servizi sono in ottimi rapporti, anche se il server è Un-managed ma mi ha comunque dedicato tempo e risorse (ad esempio abbiamo ottimizzato il my.cnf), ho anche provato alcune mod gratuite ed una a pagamento ma senza risultati apprezzabili.
Il MySQL è alla 5.5.24 con InnoDB.

Ciao

Parse Time alto Query Time basso per le pagine nonostante l' alto numero di Query 43523!

Devi prendere in considerazione di avere un problema con la banda perchè si crea il classico collo di bottiglia e dovresti quindi parlarne col tecnico dell' Host fornendogli i dati sopra menzionati.

Controlla poi da Admin-> Strumenti->Chi è in linea se vi è molta attività da parte degli utenti o da server terzi o a limite se disponi di un servizio statistiche, di controllare gli accessi giornalieri.

Comunque andando sempre per esclusione suggerisco di fare un' ulteriore operazione:

Forse il tuo sito ha generato un gran numero di file di log di debug, che possono causare rallentamenti.

Utilizzando un programma FTP scarica dalla cache del sito il relativo file di log e analizzalo se ci sono degli errori.

E' possibile eliminare i files di log da Admin-> Strumenti-> gestore Negozio-> Elimina i file di log opzione di menu.

Inutile dirti che anche se l' operazione è di normale prassi, non mi assumo nessuna responsabilità, per cui fai sempre un backup del database prima di agire.

Ci sarebbero altre cose magari te le dico dopo...

Ho temporaneamente disabilitato la generazione dei log di errore e svuotato la relativa cache (c'erano dei vecchi log di problemi "conosciuti")

Non ci sono in linea utenti "strani", giusto il solito "Baidu" (ip bannati), Googlebot etc.

Per le statistiche utilizzo solo Google Analytics.

Ciao

Sarà una mia impressione ma ho notato che il Parse Time si riduce per talune voci di categorie a circa 6 secondi.

Hai troppe categorie e sottocategorie.
Fai questa prova:
Vai in Admin-> Configurazione-> Mostra Contatori di Categoria impostato su "false"
Lo stesso in Admin-> Configurazione-> Mostra Contatori di Categoria lato Admin (meno probabile) impostato su "false"

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.