non-cached load time

Posts: 34
Joined: 08/19/2007

Cache activity for larger catalog
Hi Im using ubercart with a 6000+ product catalog I am wondering how the cache-ing works here is the scenario

* only basic modules installed (uc- events - devel)
* dedicated lamp server
* we have been moving products between categories to fine tune (which presumably clears cache for that page)
* when going to a catalog page it usually takes 60-90 seconds to return the page results
scenario 1
* main slow downs are (according to devel module) pager query
25219.44 1 pager_query i.e. 25 seconds
56321.81 1 pager_query and 56 seconds
and a few other ones that were over 5ms

* when going to page 2 (pagination)
57291.01 1 pager_query

* when I go a page the next time ( a previously visited catalog pg) it loads much faster ( 5 or 6 seconds) with cache_get coming in at 11ms - so obviously the cache-ing works for (auth and anonymous) users

So that is the scenario... here is the questions
1) Does the cache clear it self every x hours/days
1a) how to avoid this?

2) Is there a way to pre build the cache other than visiting every page manually
2a) If a site admin adds/moves a product how can we rebuild cache for that page, other than manually visiting it

3) Is there any other cacheing going on (local computer/isp/etc)(im guessing yes but nothing substantial relating to the issue in question)

4) When drupal/uc builds a catalog page from a http request does it build it out for all products (taxonomy children) in catalog (6000) or in that section (1000) or in a subsection (100)
4a) if you go to page 2 (pagination) is that then cached (i dont think it is as per scenario above)
4b) would the number of products per page (currently 10 in basic rows) make a difference to non cache load time and cached load time?
4c) I will eventually turn on the catalog grid would this be another performance hit?

5) Would server hardware upgrade help additional RAM / faster prosc. / allocate more mem to php? ( i think the server is a mid range p4 with 512 or 1gb ram)

6)what should i focus in on to address the core problem of long load times for non cached pages due to pager_query time to complete.

I realize this is a bit convoluted... I can include screen caps if req.
any insight would be greatly appreciated...uber-thanks in advance...

Posts: 5269
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Whoa... sounds like while the caching issues are being discussed, we really ought to consider optimizing that pager query, too. Shocked

Posts: 2244
Joined: 08/07/2007
AdministratoreLiTe!

I wouldn't expect pager_query to take that long because it only looks for the products in a particular taxonomy term. Even if you have an excessive number of products in a term, the fact that pager_query uses (indirectly) the LIMIT keyword it should prevent the database from getting all of the products. If you have phpMyAdmin or something, try running the queries manually. That may tell you why it takes so long.

We use MySQL's query cache which has been a big help in reducing load times. I don't really think about this problem too much so that might be all the advice I have.