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

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

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.

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.

Buondì, come si evince dalla firma, sono palesemente di parte. Ma lo sono diventato nel 2004/2005 dopo aver valutato entrambi i software (più altri ancora) e aver quindi scelto Zen Cart.

A mio avviso la maggiore 'forza' di Zen Cart è la lungimiranza. Dietro a Zen Cart vedo un progetto, ben delineato, con traguardi definiti (testimoniati peraltro dai frequenti aggiornamenti). Cosa che non vedo in OsCommerce.

D'altro canto per qualcuno i frequenti aggiornamenti potrebbero rappresentare un fastidio. Vero, ma lo reputo un prezzo vantaggioso per ottenere un prodotto sempre migliore.

Oscommerce, è vero, ha più contribs esterne, ma semplicemente a causa del fatto che da più tempo è sul mercato e quindi ha una community più vasta (per ora ;)).
Tuttavia sono convinto che se una software house si trovi a dover scegliere tra ZC e OsC, punterà su ZC perchè già ora (e sempre di più) garantisce una maggiore scalabilità e 'facilità' di personalizzazione.

Non mi riferisco a interventi di cosmesi, ma a interventi sulle funzionalità.
E la facilità di personalizzazione non si riferisce alla semplice modifica del codice (sostanzialmente non cambia granchè) ma sul fatto che in ZC è possibile modificare il comportamento del motore senza intervenire sui files della distribuzione (non sempre e non completamente ma la direzione intrapresa è quella).
Ovviamente questo comporta un vantaggio notevole per lo sviluppatore (in termini di semplicità di diffusione e di manutenzione del proprio lavoro).

A mio avviso un esempio di questa logica (anche se implementata in modo completamente diverso e ahimè (nel senso che se anzhe ZC fosse così 'aperto', sarebbe meglio) migliore) è Joomla. E credo sia sotto gli occhi di tutti la crescita esponenziale di questo CMS.

Infine una chiosa per chi non conosce i 2 software: ZC è nato nel 2003 come fork di OsCommerce quando il team di sviluppo di OsC sentendosi frenato nello sviluppo ha deciso di abbandonare Harald Ponce de Leon (fondatore di OsC) per continuare per la propria strada. Da quel momento in poi OsC è stato portato avanti solo dal fondatore (a parte svariate persone che si occupano di localizzazione). Anche questo a mio avviso è un punto a sfavore di OsC, come insegnano phpnuke, e mambo->Joomla.