Context for Vocabulary block
Imago - January 9, 2008 - 21:22
| Project: | Taxonomy context |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
Hello,
Comparing the time of loading a standard Browse category page
http://www.scindex.org/top
and a Contextual browse page, say this
http://www.scindex.org/science
shows that the latter is 10 times slower to load.
The Node Browser (based on taxonomy and computing the number of subcats and nodes)
http://www.scindex.org/node_browser/nodes_by_category/term/6
is also much more faster than the contextual browser.
There are so far 5000 terms in the vocabulary, and I am afraid, when they get 10000 or 20000, the contextual browser will never load.
What is the possible reason for this drawback?
Thank you
#1
After an a single initial run:
Loading: http://www.scindex.org/top took 23.4 seconds.
Loading http://www.scindex.org/science took 49.8 seconds.
A simple explanation for the increased processing time on the second page is that you are traversing into another level of categories (the Science Category is expanded). This means additional processing and more data and meta data is being loaded.
So you should always expect the second page to load slower.
After a second run:
Loading: http://www.scindex.org/top took 15.2 seconds.
Loading http://www.scindex.org/science took 15.3 seconds.
Server-side caching appears to be the explanation for the reduced load times during the second run.
But perhaps there is a bottleneck somewhere in the fetching/rendering of the tree. If someone could do a performance analysis on the script we could identify if/where processing can be reduced.
Anybody know of a good code profiling tool to use with Drupal?
#2
Thank you.
My time is 2 seconds and 10 seconds.
Running the today's update.
Have also committed the caching patch of today
http://drupal.org/node/180014
#3
Your times are much faster than mine. Did you clear your local cache between requests? If not please clear your local cache between each request and post the results again.
The part of the module that is in question for performance is where the vocabulary terms are fetched from the database and then rendered. This includes looping to traverse the taxonomy tree. Caching could be directly implemented here to help performance but to truely speed processing this portion of the code should be examined to see if/where processing can be reduced.
The caching patch implemented in issued #180014 only affects breadcrumbs and is more useful for integrating views with taxonomy so that patch didn't enhance performance for the pages in question.
#4
No one is working on the 5.x branches.