Long, dark night of “the loop”…

  • I’ve gone from 0 to just over 2000 posts on my site in just under two months. My initial render time was about 0.10 seconds and it’s now over 2.0 seconds. This is worrying and I need to understand more about why performance is degrading so quickly.

    The way I understand “the loop”, WP is pulling the 10 most recent posts, then stopping and displaying a page with a navigation menu. (I’m using Scriptygoddess’ WP Paginate plugin for the nav menu. It displays the total number of pages, which I assumes it calculates from a table’s row count.)

    If that’s how the loop works, then why would it make any difference to render time how many records there are?

    I know there are caching plugins, etc., that can help here. At the moment, though, I just want to understand what the problem is. I’m hoping to build this database at a rate of 15,000 entries a year, but I’m not a programmer and don’t want to have to hack my way to acceptable performance. Should I be looking at a different platform (e.g., Drupal or some other “enterprise” CMS)? Can WP manage a database of that size efficiently?

    I’d appreciate any thoughts or advice.

Viewing 15 replies - 31 through 45 (of 55 total)

  • There is an argument brewing in this thread which has a place on some sort of hardcore coding forum, but not here. The vast majority of people don’t have the passion about this.

    BUT

    As someone who answers posts here to help others, jerome’s diagnostic plugin will prove VERY useful when posters are seeking help for slow sites.

    jerome++

    Thread Starter hooopla

    (@hooopla)

    As someone who answers posts here to help others, jerome’s diagnostic plugin will prove VERY useful when posters are seeking help for slow sites.

    Seconded. I’m setting up a test instance this morning to try and nail this problem and Jerome’s plugin will be where I start.

    All I’m getting right now is:

    <!– 16 queries. 0.403 seconds. –>

    Which is cool, but might be too little information to track down a source of trouble…?

    But it’s very cool. I personally think that speed is one of best things about WP, and any work done to improve/maintain speed is great to see. So, thanks!

    Sorry I turned the thread into an argument, I don’t like to see mis-information going un-refuted.

    Just to add something productive to this post, here are other things to consider when thinking about performance:

    1. MySQL tuning
    2. Web server tuning
    3. Turn off plugins one by one to see if one is being bad
    4. Ask your service provider if they’re having problems
    5. Caching

    I’ve had a couple of days when response time on my blog has been horrible. Both times it turned out to be a problem on the server that my provider had to sort out.

    Thread Starter hooopla

    (@hooopla)

    Which is cool, but might be too little information to track down a source of trouble…?

    Read the plugin’s instructions (i.e., view the plugin using an editor). You need to turn on SAVEQUERIES and then view the output in page source. There’s lots of useful information there.

    Hey darkcanuck, thanks for that quick-n-easy diagnostics code snippet…

    (someone’s got to make those next/previous page links a little more obvious… and fix the thread feed links)

    trevorturk, make sure you enable SAVEQUERIES as pointed out by hooopla. If it could be turned on in the plugin I would have done it, but alas this is not possible.

    LoneBoat et al, you’re very welcome. This plugin doesn’t do very much, but I’m glad that you find it useful.

    Thread Starter hooopla

    (@hooopla)

    OK, here’s what I’ve found out using Jerome’s diagnotic plugin.

    The WP Paginate plugin appears to be reading every row in the table in order to determine the total number of records — rather than using a row count. In case anyone’s interested in seeing the output from Jerome’s Query Diagnostics when this plugin is activated, here it is. (Queries 4, 5, and 6 seem to be looking at every post.) Compare with no plugins activated here. Since what I know about MySQL fits on the head of a pin, I could be totally wrong, but I’ll follow up with the plugin author and see what she thinks.

    Thanks again for everyone’s help with this problem.

    Oh my…

    The query to look at is [3] (as ugly as [4] and [5] look, [3] is the real troublemaker):
    – in the no plugin version, the query is limited to the first 10 posts
    – with plugins activated, the query grabs all posts every time.

    Besides the extra query time, this may cause WP to try to preprocess all of the posts returned.

    Thread Starter hooopla

    (@hooopla)

    – in the no plugin version, the query is limited to the first 10 posts
    – with plugins activated, the query grabs all posts every time.

    I have Options>Reading>Show at most set to “10 posts”, so I’m guessing that WP Paginate overrides that setting and grabs all posts in order to do its own calculations. Is that a reasonable interpretation? (I’m asking because I want to communicate as clearly as I can with the plugin author and I don’t totally understand what the queries are saying.)

    3 is bad, but 4 and 5 show some nasty things going on as well. Why are there a couple hundred posts being processed every pageload?? One is a comment-count thing (which I hate… maybe it’s time for a plugin), the other is something similar but for meta fields.

    -d

    ah, sorry about missing those instructions. this is a really cool plugin – thanks!

    Thread Starter hooopla

    (@hooopla)

    3 is bad, but 4 and 5 show some nasty things going on as well. Why are there a couple hundred posts being processed every pageload?? One is a comment-count thing (which I hate… maybe it’s time for a plugin), the other is something similar but for meta fields.

    Hmmm… I don’t even use comments on my site. ??

    I’m guessing that those posts (actually everything in my database) are being processed to arrive at a total_posts number in order to calculate total_pages and display that in the navigation menu at the bottom of the page (i.e., the “Page: 1 | 2 | 3 | … | 220” stuff).

    The meta field query I have no clues about. If it’s in the only_wp-paginate.txt file but not in the no_plugins.txt file, then I can’t guess.

    I didn’t get the plugin to work. I am working with my adaptation of Classic and I don’t find a line “that includes the file wp-blog-header.php”, or is that get_header(); ? I placed define (‘SAVEQUERIES’, true) before that line, between the <?php ?> thingies.

    And I don’t find do_action(‘wp_footer’); but instead something like wp_footer();

    I placed the do_action() before wp_footer, behind, and as a replacement.

    Stumped.

Viewing 15 replies - 31 through 45 (of 55 total)
  • The topic ‘Long, dark night of “the loop”…’ is closed to new replies.