Find content
Female
Jan Zonjee, on 09 October 2010, 10:54, said:
It might have been always slow because it is. It joins a pretty big number of tables in the query. So with a large number of products (so big tables) things start to get slow.
I don't know of any contributions that handle this (although I have an idea on how to try to tackle this, but fail a large site to try it on). In the upgrades an index to the table specials was added that might help here:
An idea might be to install a contribution to see how many queries a page generates and how long it takes to execute them (find excessive amount of queries or slow ones) : KissER Error Handling & Debugging (needs PHP5.2 or higher so no problem for you here).
I don't know of any contributions that handle this (although I have an idea on how to try to tackle this, but fail a large site to try it on). In the upgrades an index to the table specials was added that might help here:
alter table specials add index idx_specials_products_id (products_id);
An idea might be to install a contribution to see how many queries a page generates and how long it takes to execute them (find excessive amount of queries or slow ones) : KissER Error Handling & Debugging (needs PHP5.2 or higher so no problem for you here).
A client's store was taking an average of 30s to load subcategory pages. The specials table had almost 4000 products and it was slowing down the whole store. Dropped the specials table, the store run smooth. But of course this was not the answer, for every store needs to have specials.
This little command did the trick and now the store is running fast like a Ferrari.
Tks a lot!!! Just want to bring this back so it might help other people.
