It was almost exactly one year ago today that I posted about what has become the final version of the Checkbox Challenge comment blocker for my WordPress blogs. At that time I was logging the comment attempts and the results of the challenge to a text file. Now I log things to a database so I can search them easier. I had thousands of entries in the text file log before I switched, and I did not bother to convert them. (I just checked; the text file was used from January of 2007 to August of 2007 and contains over 22,000 lines of data.)

The database logging process was added on August 1, 2007. So I ran for about seven months without the database log, and now have run for just over six months with the database logging in place. The results are, frankly, both astounding and a bit scary.

More…

I have been spending my free time working on my other board, so I have not managed to get the analysis done yet for the various template statistics that I captured. What I plan to do is keep exactly 1,000 page refreshes for each template for each trial. I will do this by taking the middle 1,000 results and tossing the best and worst times. This should help provide a better indication of the true performance of each engine.

I do, however, want to complete this before I relaunch the board I am working on as I will include whichever template engine performs the best with that upgrade. So hopefully I will be back to this in the next week or so. Thanks for your patience.

I have had frequent complaints from folks on my biggest board regarding the search results. It seems that for many users page two (and beyond) was not available. Frankly, I was stumped. I worked with some users to verify that they have cookie settings that work and to ensure that their search session was not timing out. I checked (and tweaked) the code that clears out old search sessions to make sure their search results were not being truncated too early. The main thing was, I was never able to reproduce the error. That makes it very frustrating when trying to debug and fix an issue.

It turns out that the root cause had nothing to do with a cookie or session problem. The cause was that these users were running searches that returned a huge number of posts or topics. I figured that out by looking at the MySQL query logs and noted something specific to this issue.

Why should the number of resulting posts matter if I am only trying to go to page 2? Shouldn’t it be an issue only if I am trying to view page 800 instead?

More…

I have completed the data collection phase of the template testing. I have run 10 different scenarios all on my isolated development server. A couple of scenarios are going to be tossed from the final results due to bugs in code or collection anomolies.

So here is what I have to evaluate:

More…

In Part I of this series of posts I detailed the results from my first benchmark scenario. For that scenario I only ran one session. What I mean by that is I had a single browser window open. With the meta refresh keyword set up in my overall header template I could start a refresh and walk away from the system and let it run for hours.

Given that I have four template engines to test and I want to capture statistics based on at least 1,000 page refreshes for each template engine for each of the four pages in my test case that is… hmm… carry the … multiply…

1,000 refreshes * 4 template engines * 4 pages * 2 second refresh interval

… that’s 32,000 seconds, or roughly one third of a day. I certainly don’t have the time to sit around and do nothing but watch a browser session refresh all day. So it’s nice that I can start the process and leave it alone.

What other test scenarios do I have planned?

More…

The author of the code I have been testing has started a development topic at www.phpbb.com. So if you want to try the same code that I have been testing, you can to that.

Speedy Template Development Topic

The MOD Author is Brainy. I like their current signature line…

if($do || !$do) $there = $no_try;

Collecting Data

In an earlier post I detailed how I was capturing the time spent parsing a page. The code looks like this:

$page_parse_start_microtime = microtime();
$template->pparse('body');
$page_parse_time = microtime_duration($page_parse_start_microtime, microtime());

The call to the pparse(’body’) function appears at or near the bottom in essentially every content page in phpBB2. By including this code I capture the start time just before the function call, and get the completion time after the function returns. One astute reader pointed out to me that this ignores the parsing time spent in rendering the page header and the page footer, and they were right. But I don’t think it matters. Besides, I don’t want to alter my testing process now as I would have to go back and start all over again, and I don’t want to do that.

Why doesn’t it matter?

More…

Trial Number Two: A New Hope

If George Lucas can get away with starting with Episode IV then I can start with trial number two, right? Well, there is actually a reason for it. Trial number 1 was really just a POC (proof of concept) to show that the techniques I outlined last time for capturing parsing and page generation times would work. The first trial was also run before I was also given a tweaked version of the Categories Hierarchy template engine to use. Trial number one was also run on my production server which meant that the template engines were not given a “quiet system” to work with. As a result, I will skip right to the second set of numbers.

More…

Our story so far…

I have a board with nearly 400K posts and 30K users. This board has paying sponsors which means I am able to afford a nice server to run it on. However, I am always looking for ways to tweak the code and get every tiny bit of performance that I can. My background is in databases, so naturally I started with the query logic and index structures and so on. I have a couple of posts so far (see Related Links) that show how I tested the performance impact of those tweaks. It was during that process that I discovered that my queries are not the problem.

It’s the parsing engine.

More…