Let me know if you encounter any problems with the new site.

There were a lot of motivations for writing my own archiving system, but the primary one was efficiency. While I considered trying something off-the-shelf, so to speak, like ComicPress or Drupal, I really wanted something that would be blazingly fast yet still dynamically generated to let me do things like GPF Premium on the server side, primarily for security reasons. (Server-side processing means no messy JavaScript is required by the users, thus exposing them to less risks, while Premium content doesn’t even get sent to the browser at all if Premium isn’t enabled.) So the GPF site is optimized out the wahzoo, with certain high-volume pages built once by nightly crons while others that require more interactivity reduce database queries to simple selects as much as possible. I’m never one to brag and toot my own horn, but I’m actually pretty proud of the new site and how responsive it is.

Of course, I can’t really take all the credit. I do have to give some serious props to XCache.

For those unfamiliar with PHP, it is one of many server-side, interpreted scripting languages commonly used for dynamic Web site development. The caveat, however, to any interpreted language is that on each request the source script must be read, parsed, compiled, and executed before anything is set back to the end user’s browser. This is one reason why dynamic sites are and will always be slower than serving purely static HTML files. Static HTML just needs to be read and regurgitated; anything that requires the Web server to actually think takes more time. Add to that the fact that there could be hundreds or even thousands of requests all competing at once for content and it’s a miracle anything get served at all.

XCache is one of several opcode caching extensions for PHP. Essentially, when the first request for a script is made, the script is parsed and compiled as usual. However, XCache stores the compiled code so subsequent requests can skip the parsing and compilation steps and go directly to executing the code. This significantly increases the speed of execution by eliminating one of the costliest parts of the process (except perhaps database connections). In addition, XCache also includes the ability to cache variables and objects, so commonly repeated and expensive variable generation–such as the cryptographic hashes I use for salting cookie hashes or database look-ups for common elements like the Premium subscription levels–can be stored in the cache rather rebuilt on each request.

I was first introduced to XCache by the XCache for WordPress plugin, which was probably mentioned in one of the development feeds built into the WordPress dashboard. I’ve been running this combination here on the blog for a little while with moderate success; I’m still trying to find a good balance of configuration settings to get the best results, but I’ve been happy with the results so far. Without putting much thought into it, I went ahead and installed XCache on the GPF server, hoping that it would help even if I never got a chance to optimize it. Fortunately, it has helped, and now that I’ve optimized the settings it’s exceeded most of my expectations. I’m not sure if there’s something about my code that caches better than WordPress, but GPF has done much better with XCache than the blog has.

Admittedly, I haven’t compared it to any other opcode cachers, nor have I benchmarked it against any of the competition. That said, however, I heartily recommend it to anybody running PHP applications. To get the greatest benefit, you may need to modify some code (or install a plugin if you’re using a prepackaged application) to take advantage of the variable/object caching. But even without modification the opcode caching alone makes for a vast improvement.

Anyway, WordPress usually includes some default feeds in the Dashboard after you log in, mostly from WP developers. One recent entry linked to a “geek ramblings” post about creating a secure WordPress install, which in turn references a WordPress security whitepaper over at BlogSecurity. (If you didn’t know any of these sites existed, don’t feel bad. Neither did I until today.) There’s lots of interesting reading there, especially if you’re (a) interested in securing your WordPress site and (b) you happen to be curious and/or adept enough to dabble in a number of arcane Web server settings. I happen to fit both of those criteria.

One of the main reasons I’m mentioning this is that there might be a few changes and improvements for folks who have registered to comment. The site now redirects you to a secure SSL page on login, and your cookies will be stored in secure mode too, meaning they can’t be read unless sent over an SSL connection. This might require you to log in the next time you try to comment, even if you’ve told the site to remember you, because the old cookies won’t be secure and will need to be reset. Otherwise, you probably will never notice the difference unless you go to edit your profile, which most of you probably will never worry about once you’ve registered.

The rest of the changes are all behind the scenes, so I won’t bother you with them. Just read the links if you’re curious. I’m experimenting with some arcane Apache mod_rewrite rules to really locking down the admin pages, all outside the scope of the links listed above, but so far those tests don’t seem to work. However, if I get them to do what I want, I might post them here (to give back to the community and all). It will be pretty sweet and borrows a few ideas from recent episodes of the Security Now! podcast (#113 specifically) to lock down access to the admin site from only certain locations or certain roaming computers.