Support » Fixing WordPress » [Plugin: Simple Tags] Slow query in 1.5.7

  • distobj


    Hi. We’ve recently started using this plugin and have noticed the sites’ performance slowing considerably. Some debugging turned up a query which was regularly taking a long time, and sucking up a *lot* of CPU;

    # Query_time: 8 Lock_time: 0 Rows_sent: 15 Rows_examined: 72220
    SELECT t.*, tt.*
    FROM wp_terms AS t
    INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id
    INNER JOIN wp_term_relationships AS tr ON tt.term_taxonomy_id = tr.term_taxonomy_id
    INNER JOIN wp_posts AS p ON tr.object_id = p.ID
    WHERE tt.taxonomy IN ( ‘post_tag’ )
    AND p.post_date_gmt < ‘2008-10-27 23:24:03’
    AND tt.count > 0
    GROUP BY t.term_id
    ORDER BY tt.count DESC
    LIMIT 15;

    Has anybody else encountered this problem, and if so, what have you done to alleviate it?

Viewing 15 replies - 1 through 15 (of 18 total)
  • iridiax


    Why not use a different plugin or a non-plugin option? This plugin only states that it is compatible up to WordPress 2.5.



    This is a truly great plugin. That’s why we’re hoping that the author updates it.

    I agree, that plugin needs some serious performance improvements.

    If you have tips for optimize my plugin… please contact me…

    I am having these slow queries as well. the plugin is perfect and great but I keep getting lots of slow queries. of course i dont know how to optimize it and i m not here to criticize its author since he has done an excellent job. I am here to let him know that his plugin *maybe* has got some performance issue. Apart from this i love Simple Tags. The slow queries i am getting are the same as distobj. it took me a while to figure where they came from. Is anyone else having this issue? what can we do to solve it? Caching the blog? Limiting tags on posts? Any reply is very welcomed!

    here are my slow queries:

    Tue Mar 31 13:01:03 2009
    # Query_time: 8 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
    use mydatabasename;
    SELECT p.post_title, p.comment_count, p.post_date, p.ID, COUNT(tr.object_id) AS counter
    FROM wp_posts AS p
    INNER JOIN wp_term_relationships AS tr ON (p.ID = tr.object_id)
    INNER JOIN wp_term_taxonomy AS tt ON (tr.term_taxonomy_id = tt.term_taxonomy_id)
    WHERE (tt.taxonomy = ‘post_tag’ AND tt.term_id IN (“71”, “187”, “3”, “138”))
    AND p.ID <> 2090
    AND p.post_status = ‘publish’
    AND p.post_date_gmt < ‘2009-03-31 13:00:55’
    AND p.post_type = ‘post’
    GROUP BY tr.object_id
    ORDER BY counter DESC, p.post_title DESC
    LIMIT 0, 6

    # Tue Mar 31 13:02:21 2009
    # Query_time: 2 Lock_time: 0 Rows_sent: 0 Rows_examined: 0
    use mydatabasename;
    SELECT wp_posts.* FROM wp_posts WHERE 1=1 AND YEAR(wp_posts.post_date)=’2009′ AND MONTH(wp_posts.post_date)=’2′ AND DAYOFMONTH(wp_posts.post_date)=’9′ AND wp_posts.post_name = ‘blog article’ AND wp_posts.post_type = ‘post’ ORDER BY wp_posts.post_date DESC

    I had these issues amongst others on my blog. I have 15,000 posts with 5,000 tags, so my relationships table is getting a little swollen (104k rows).

    As i couldn’t debug it, I started caching (which helped a little), then removed some of the more frequent tags from my posts. I had some tags for example with 9,000 occurences, so deleting them had a big impact on my relationships table, and overall CPU usage by MySQL.

    I managed to get server load down from 2.00 to 1.00 doing this. It’s only a temporary fix, and i need a long-term resolution too.

    Can I ask how you guys narrowed it down to these specific queries?


    That being said, I just ran the 2 pieces of code posted above by france with the following results.

    Showing rows 0 – 5 (6 total, Query took 0.0857 sec)

    MySQL returned an empty result set (i.e. zero rows). (Query took 0.0016 sec)

    Still any pointers on finding & debugging slow queries who be great, as somewhere in my install I have probs 🙁

    i didnt debug it at all to tell you the truth. How did i reckon what it was simple tags to create those queries? Simple. I have few plugins on my blog (only 10 plugins). I started disbling them one by one, also trying to enable them by couples, triplets etc. This process took around 10 days. In the end every time i enabled simple tags alone or with other plugins, the slow queries appeared. I know this is not a very professional way to find out what plugin was the culprit, nonetheless i found out what was causing my queries.

    by the way, what if i index my database in a better way? I have heard that this could help a little bit. If you think that this may be useful, where can I get help? do you know a professional site able to offer valuable help?

    I was going to start looking around for a freelancer to take a look at it, but it’s not got bad enough to part with cash yet! 🙂 I’ve had good experiences with some freelancers for Joomla, WP should be no different.

    Good Luck!

    Does the same with mine – I have 10,000 posts and 6000 tags and I can’t leave it running as the sleeping queries bring the whole things to a halt.

    I have only 1300 posts and 90 tags but it is the same. I also think that these slow queries are caused by servers themsevles. in fact if you are on a shared server *maybe* simple tags can give you some issue. But this is a thought of mine…what do u think?

    Mines on my own VPS

    I’ve been having a problem which I think is related to SImple Tags, that causes high CPU and active MYSQL connections not closing.


    I’m now wondering having read all the above comments by people whether the two are related.

    I like the functionality of the plugin and am the first to admit I wouldn’t have a clue where to start in writing one, but if the author of SImple Tags could have a look at this we’d all be very grateful.

    Mine is on a dedicated Dual Xenon, with 2 other sites. Both other sites load pages in ~1sec. Something in my WP install though is making sites on this site load in ~6 secs.

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘[Plugin: Simple Tags] Slow query in 1.5.7’ is closed to new replies.