Eventually I noticed that not all traffic surges were created equal. It was really only the ones that linked to DM of the Rings<\/a> that crushed my site. Links to other stuff wouldn’t even cause a hiccup, even if the overall traffic spike was larger. The natural assumption is that it must be due to the fact that the comic is image-heavy. Except, this problem persisted even when the images were moved off-site. Hmmm. What about the scripts that set up all the comic navigation stuff? That seems like a stretch. Perhaps the script I wrote that embeds images so I don’t have to clutter up my prose with a lot of HTML? Meh. It might be inefficient, but I can’t imagine it’s anywhere near bad enough to bring down the site where the average comic was one or two images. But what else could it be? What else makes the comics different from the other posts on my site?<\/p>\n I’d ponder this problem for a day or so and then forget all about it until the next time my site went down. This cycle has been repeating itself for a couple of years now.<\/p>\n I’ve finally figured it out. And I am really embarrassed at how long it took me.<\/p>\n It’s the number of comments. Also: Duh.<\/p>\n I was always looking at the early comics, where the comment count is a couple dozen or so per entry. Later in the series the comments regularly top a hundred, and the finale clocks in at just under seven hundred comments. <\/p>\n I run some tests on my local machine, where I have a functional mirror of this blog. It takes my machine an agonizing three and a half seconds<\/strong> to generate the page for the finale. Now, I’m sure the server at Hosting Matters is many times faster than my humble computer, but 3.5 seconds is still insane. Get a few thousand people in there chewing through those high-comment posts, and it’s easy to see how they could render the machine helpless. I try disabling the display of comments and it is able to generate the page in just 0.14 seconds. So 96% of the CPU time is spent churning out the HTML for the comments, and the other 4% is spent on everything else<\/em>. <\/p>\n But why? Why is it taking so long to list the comments? My first thought is that this is caused by my dice roller. The code to display the dice for a comment is a recursive operation that subtracts from a number and then calls itself until the number is zero.<\/p>\n As of this writing, the current comment count on the DM of the Rings finale is 678. This requires ten levels of recursion. (Six 100 sided dice and four 20 sided dice.) Keep in mind it has to roll a handful of dice for each and every comment in the list, with the number of dice needed gradually going up. <\/p>\n Lots of dice times lots of comments time lots of comment-heavy posts = a crap-ton of HTML. <\/p>\n Every comment has a bunch of HTML around it. Nested DIV tags and SPAN tags and TABLE tags and… wow. This is really messy. There is a lot of extra stuff in here. I remember how this came about: Most of it was for cross-platform reasons. The differing behaviors of IE 6, IE 7, and Firefox were crazy to sort through, and often making very slight changes would blow out the formatting on one browser or another. Once I had it working, I stopped messing with it because I was pissed off and sick of fighting with it. So I left this crufty mess in place, even though I most likely don’t need the majority of it.<\/p>\n Just to make sure I’m getting a clean test, I remove ALL of this extraneous HTML. I just have a single line-break between comments, but otherwise they are a big jumble. That’s fine. I’ll sort that out later. Finally, I disable the comment editing plugin and SuperCache so that I can be sure they aren’t part of the measurement. <\/p>\n The code that is left is as streamlined as it gets: WordPress yanks comments out of the database and spews them onto the page without doing anything else. It now takes almost exactly 2 seconds to build the page. Nice, but I have a feeling there is still a really big bottleneck in here someplace.<\/p>\n Time to get systematic. Each comment has several distinct parts:<\/p>\n 1) The comment number Hm. So which of these steps would be the most time consuming? My primary suspects are #2, #3, and #9. Time to run some tests. I’m going to disable an item, reload the page a few times to see how much time it saves, then re-enable it and run the same test for the next one. This test isn’t super-accurate. Values jump around in 0.05 increments, but considering how huge our bottleneck is this shouldn’t be a problem.<\/p>\n But let’s see how it goes…<\/p>\n
\n2) The dice
\n3) The avatar
\n4) The name \/ link of the author
\n5) The permalink of the comment itself, which is wrapped around…
\n6) The date on which the comment was made and…
\n7) The time of day of the comment
\n8) An admin edit link (just for me)
\n9) The actual comment text<\/p>\n
<\/td><\/tr><\/table><\/p>\n