It is now taking approx. 58 seconds to put up the initial list of nodes. I thought the db query might be slow so I checked into this thinking maybe I could add an index somewhere. Fishing throught the module, I think this is the first query caled:
SELECT DISTINCT(n.nid), n.type, n.title, n.created, n.changed, n.sticky, u.name, tn.tid FROM node n INNER JOIN users u ON u.uid = n.uid LEFT JOIN term_node tn ON n.nid = tn.nid WHERE ISNULL(tn.tid) ORDER BY n.sticky DESC, n.created DESC
I ran this in Mysql command line and it returned 749 rows in 0.12 seconds - not terrible. Then I ran
EXPLAIN SELECT DISTINCT(n.nid), n.type, n.title, n.created, n.changed, n.sticky, u.name, tn.tid FROM node n INNER JOIN users u ON u.uid = n.uid LEFT JOIN term_node tn ON n.nid = tn.nid WHERE ISNULL(tn.tid) ORDER BY n.sticky DESC, n.created DESC
to see if there were indexes and got this:
+----+-------------+-------+------+---------------+------+---------+---------------+------+---------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+---------------+------+---------+---------------+------+---------------------------------+ | 1 | SIMPLE | u | ALL | PRIMARY | NULL | NULL | NULL | 15 | Using temporary; Using filesort | | 1 | SIMPLE | n | ref | uid | uid | 4 | db03.u.uid | 44 | Using where | | 1 | SIMPLE | tn | ref | nid | nid | 4 | db03.n.nid | 16 | Using where; Not exists | +----+-------------+-------+------+---------------+------+---------+---------------+------+---------------------------------+
Really doesn't look bad - I don't think this is the problem.
Next I looked a firebug: profiling the javascript it look like there are over 64,000 calls and the longest ones each take multiple seconds most going to the jquery e (eval) function. I'm not much of a ajax guy so I'm not sure what to do next. Maybe I'll turn off all node types except pages (I have a few cck node types)
It seemed to worked fine when I had fewer nodes but now that I have over 1100, it has become very slow .
Any thoughts on improving performance are appreciated
Comments
Comment #1
ghankstef commentedTo follow up - after eliminating all content types but page from the types of content available in link to content, initial load improves from about 58 seconds to 42 seconds. Yet, limiting to a cck type only with only 30 nodes (all others off) still took 47 seconds - not sure I am on the right track here
Comment #2
stborchertHi.
Sorry for responding so late but I'm currently writing my final thesis.
Hm, this sounds strange. There was an issue where the query hangs because of too many nodes. After this I removed
node_load which has been called on every node.But 47 or 58 seconds and 64.000 js-calls are definitely too much.
I don't have an idea atm to solve this problem, so please report if its working better.
The next version (for drupal 6) will have a pager so there are only a few nodes loaded.
Comment #3
stborchertPlease reopen if still active.
Comment #4
nath commentedWe have the same problem.
Comment #5
nath commentedI'm pretty sure now that it is caused by having a large taxonomy.
Comment #6
stborchertHow many taxonomy entries do you have?
I hope to have the time to work on a new version next month. This version will include pagers so only 20 or 50 (as you configure it) items are loaded at once.
greetings,
Stefan
Comment #7
nath commentedI've changed the code a bit so that only one taxonomy is loaded and now it is much faster. I think an option (checkboxes) which taxonomies one wants to use would be a good first step.
We've got 10 taxonomies, two of them with hundreds of terms the rest has only a few.
Comment #8
stborchertItem lists should be displayed with pagers (number of items configurable). This avoids slow loading by exchanging a smaller amount of data between the main page and the plugin popup.
Comment #9
sunHuh? A result set of 30 nodes takes 47 seconds? Frightening numbers! I could only imagine such a performance if Linktocontent is loading the first result set (the list of nodes) via AJAX, and loads additional information for each node in the result set also via AJAX directly afterwards. That would implicate 31 full Drupal bootstraps, which, depending on the size of a Drupal site, could take up 47 seconds in total.
Do you have Firebug installed? It may provide additional information about HTTP requests performed in the background.