As much as I like Markdown, the nifty formatting syntax, it’s wicked slow. I may have to dump it just because it’s making page loads unacceptably slow. Not only that, but it slows down RSS feeds down something awful.

So while waiting for WordPress 1.3 to add caching of pages, I am investigating how to optimize performance in the meantime.

UPDATE: According to Pair, it is the web server running out of physical memory. A-hah! Although I added the staticize 2.5 plugin (which speeds page recall by orders of magnitude), it is the initial load of php.cgi into memory that is the lag…nothing I can do about that. Pair’s customer service continues to please me with their candor and responsiveness. But it will require a memory upgrade…I don’t know how long this will take.

Things I’m doing.

• Markdown is slow…there are a lot of regular expressions processing a lot of text on index.php. Without Markdown activated, pages load 20-30 times faster. So I might have to go back to handcoding HTML. Sigh.

• Installed Staticize 2.5 to speed things up. I have to modify the script slightly to not use $_SERVER[‘SCRIPT_NAME’], because php-cgiwrap doesn’t work with it (it reports the cgiwrap script). Substituting PHP_SELF seems to work. This does seem to speed things up tremendously! Version 2.5 also seems to fix the problems I had with the RSS feeds.

• LazyImageLayout provides my image markup, which I want to keep. It does generate a bunch of jpeg thumbnails the first time you run it, but afterwards there shouldn’t be a penalty. However, it has some inefficiencies here and there that I’m slowly cleaning up as I learn better ways of doing things.

• It may also be my server. It seems awfully chuggy these days. It’s slow, it’s fast. It might be the db server (which is on a separate host with the network). I’ve sent in a trouble ticket. Right now, it seems fast.

• It may be my server configuration. I’m using the cgiwrap version of PHP, which means php.cgi needs to load every time someone accesses the pages. That kind of blows, but using cgiwrap allows me to own the files that WP generates. I could write a script that deletes the files I suppose, and use the built-in PHP module in Apache to lower the load penalty. Usually it is not bad, but lately the server seems to take several seconds to load the module. UPDATE: Pair’s customer support told me that the server I’m on is running out of memory, and they’re going to look into adding more. Yep, that helped. The server was running so low on memory that it took 30 seconds to free up enough to actually run the PHP module. I verified this by SSH’ing into the host and running LYNX, the text-based browser, right on the webserver. Interactive performance was good: no lag in typing, which indicated my net connection was speedy. Actual server response time sucked. Now that they’ve added more memory, performance is much improved. A second thing that helps is to enable POSTS PAGED and limit the number of posts that show up. This speeds things up also, since Markdown etc doesn’t have to process as much text. You do have to add a line to your index.php though to actually show the “previous :: next” links.

<

p>#Problem with Staticize and Posts In The Future# With recent server improvements, I’m finding Markdown is running fairly quickly again, so I’m letting it run dynamically instead of caching output as static. Why? * When I’m queueing up posts for the future, Staticize Reloaded 2.5 isn’t aware of them. I have to manually edit an article to expire the staticize articles. I might be able to modify Staticize to run at least twice a day at noon or midnight, but in the meantime I’ve just turned it off. * To get back some of the page load boost, I’ve re-enabled GZIP compression under Admin->Options->Reading. It’s off when I’m using Staticize, because GZIP messes up its caching scheme.