An interesting turn of events has led me to tinker with the WordPress blog software. After doing some chatting on IRC the other night, I came into contact with someone needing a bit of help. One thing led to another and the topic of developing a website utilizing WordPress as a Content Management System for websites came up. I mentioned that I was aware of the project and knew that I would certainly be able to modify the source as needed to provide the functionality this customer would desire. So, off to the WordPress website I go to download the latest version to play with, as if this project did come to fruition, I wanted to be as ready as possible. Besides, it’s been a couple of years since we reworked the Gray Matter website, so this seemed a fantastic opportunity to give ourselves a new look.
I really have to point out that I am a strong advocate of open source software. The team at WordPress has done a phenomenal job at making one of the most well known and well used pieces of software on the web to date. The problem is one I see far too often in software these days, “Feature Bloat.” “Why don’t we just add a few lines and make it (insert crazy need here)?” Over the years I have seen this happen with many commercial products as well, so this is not in any way directed only toward open source software developers. I mean, really, a DVD to install an operating system (hello, Microsoft) sounds like maybe we all should think about what this software does, or more importantly what it doesn’t. An OS really should not manage my MP3 collection or help me configure my network. Has anyone installed Adobe Photoshop, Norton Anti-Virus, or Intuit QuickBooks lately? Oh how better can we waste all these newfound CPU cycles of the new Multi-Core Processors?
Anyway, enough with the rant, here were my findings on a virgin installation of WordPress 2.9.1 loading a single page. The load took roughly .20 sec which really should not be that big of a deal, or should it? During the load 16.65 MB of memory was tied up. This is starting to worry me. There were also 14 queries made to the MySQL database during the load. What does all this mean for most website owners? Really nothing, if traffic is low this should not cause too much of a headache, but what happens when your website gains popularity and starts taking in 1,000 visitors per day? Well, let’s do the math… 1,000 visitors * 3 pages viewed per visit * 16.65 MB = 48.78 GB of memory usage per day. With a typical web server having 16 GB of memory to handle EVERYTHING, including e-mail, network, DNS, and Operating System overhead, you can see that a problem is coming. Forget about that one server handling multiple domains as most do, and you can see that one server handling one domain will really be working as the figure approaches 5,000 visits/day. Memory usage at this point is 243.9 GB/day and you can certainly expect to see users hitting the wall of “Internal Server Error” as Apache starts denying requests. To be honest, there are caching plugins available, but the point here was to test the processing requirements of the application.
Again, my point is not to discredit the WordPress team in any way, but to point out to other developers to always draw a strict line when defining what the application will and will not do upon creation. If you need more features, develop another application. While backward compatibility is important, do not provide it at a decrease in performance for those that choose to run on current platforms. I really would love to see the day that we all develop the philosophy of the UNIX creators – an application should do one thing and do it very well. Piping output between small applications is still the most efficient way to handle data processing I’ve seen to date. This technique should be used whenever possible in your applications. For the *NIX impaired I introduce ‘ls | grep ‘something’ > filesThatContainSomething.txt’ this single statement utilizes 2 applications and lists the current directory, sorts out any file name that contains ‘something’, and writes it to a file. There is great power in linking together small high-performance applications to accomplish a task. The best part is re-usability, you can arrange and rearrange the small applications to do something entirely different should the need arise.
For the time being I will be using this WordPress CMS for our site, but heavy development of a much leaner system is underway now, and we will make the software available to customers who choose to utilize Gray Matter for their website needs. I envision a product that will support multiple database systems, and be strictly optimized for current versions of PHP (5.3 at time of writing) with workarounds for older versions requiring installation to support those platforms. I really like the WordPress idea of plugins, and will implement something similar in our software. The goal will be a memory usage of under 250k per request with no more than 4 queries to the DB. Wish me luck!
Edit 2.27.2010 – During the process of my creation of the CMS, a customer contacted me looking for a website. We were in a pinch so I provided them with a WordPress site and did a little more homework. The addition of a caching plug-in reduces the overall server load considerably, so maybe we will stick with WP for a while. If you are interested the plug-in I am currently using is WP-Super-Cache and was quite painless to get set up. Now WP does it’s heavy work only once per day, but you can even go out further if your content does not change often. Hope this helps you!