For those of you that haven’t yet heard, WordPress is once-more taking part in the Google Summer of Code. Google Summer of Code 2008 is a Google-sponsored program where college students are encouraged to contribute to their favorite open-source projects for a summer, and in exchange both they and their mentors receive some monetary compensation/motivation for their efforts.
I really don’t need to go into details about this much, since Lloyd Budd has done such a good job explaining what it is and what WordPress hopes to achieve in this program. This year, WordPress has an even-larger and more-exciting list of possible projects than before, along with a list of the mentors available for each idea. This Google Summer of Code, I’ll be mentoring for the WordPress projects in the one area that is closest to my heart: improving performance.
It would be unfair to say that WordPress is slow or an inadequately-performing blogging engine, because that’s not really true. "Performance," more than any other software characteristic or trait, is a very relative and subjective index. It depends on thousands of different factors, it has dozens of different baselines, and most confusingly of all, sometimes the perception of performance matters more than the performance itself.
But no matter where WordPress is now in terms of high-performance, there’s always room for improvement. Late last year, disappointed in this very blog’s less-than-stellar showing during the many Slashdot and Digg appearances (even on a damn-decent dedicated server), we decided to re-write the WordPress front-end from scratch.
You’re looking at the result now: the homepage and individual posts are powered by PerformancePress, our in-house re-write of the WordPress page-displaying code. The NeoSmart Files is still running WordPress, just behind the covers. The procedure we followed in developing PerformancePress was simple: only load what you need, don’t waste CPU cycles if you don’t have to, minimize SQL queries wherever possible, don’t loop when you can avoid it, and a number of other load-reducing principles.
The thing is, there’s a huge difference between in-house code and software that’s been "generically-developed" for use by the masses. While we could make assumptions about our own use of the blogging system, the WordPress project doesn’t have that privilege. There is no cutting-corners or jumping to conclusions on a for-redistribution project. Flexibility usually comes at the cost of optimization; and the net result can be more than a little tricky to understand.
These are some of the same reasons we cannot just "release" the current PerformancePress code we’re using here – it wouldn’t last 10 minutes in the real world. But hopefully this Google Summer of Code we will have a chance to bring out in WordPress the best of both worlds. PerformancePress is most likely a dead-end; but it’s been an invaluable experience in realizing how to create the most resource-efficient, well-scaling webapps; and hopefully we can take that to the next level this summer.
I would be interested in seeing some performance comparisons between WordPress trunk and PerformancePress under high levels of concurrency. Also, even if the PerformancePress code is not directly applicable to mainstream WordPress users, the principles likely are. It would be nice to see the code released or at least made available.
I realize that you guys are reluctant to release your highly configuration/server/environment-dependant code out to the public for many reasons (perhaps you’re worried it won’t perform as well on other configurations than yours?) but even if it’s not the answer for 99.9% of WP users out there; there is a very-capable userbase of avid code hackers that would take anything you care to dish out and make the best of it.
So what if it’ll take a day or two to strip out all the references to your own configuration? It’s better than us having to rewrite WP, especially if someone’s already done it and did a good job (i’m judging by the PerformancePress page-load times on this site).
I second what Barry says about the benchmarks – I’d love to see some stress-test results for the two systems on a “normal” dedicated server running Linux, Apache2, and PHP5.
Seriously, please consider releasing the code. After all, odds are thanks to community contributions and patches you’ll end up further increasing the performance of PerformancePress on your own server, etc. Even if you don’t feel like doing the work to clean it up and “generic-ize” it, just release it and someone or the other in the huge WP community would do the rest!
Drop me an email if there’s anything I can do to help or further convince you!
-Arnold
Barry, Arnold: I’ll see if I can’t do some load-testing tomorrow (on Apache2 and possibly LightTPD comparing WP trunk, 2.x, and PerformancePress).
As for releasing the PerformancePress code… I’ll consider the options and see what happens. I was planning on publishing it prior to the start of GSoC 2008, and using the ideas and principles from there for the performance project; but you’ve given me some food-for-thought here.
My biggest concern is that I absolutely don’t want to publish anything that can be mis-construed as a fork of WordPress. So long as it’s sitting on our server and doing its thing, it’s just a WordPress install with an alternate frontend. But once it’s released, I can easily imagine it going the same way as LightningPress (which has gone the way of the dodo), which attempted to optimize the existing WP frontend (whereas PerformancePress is a complete from-scratch re-write using completely-different architectures).
Let’s get the load testing done, then go from there, shall we? š
Yeah, it’d be awesome if you released PerformancePress!
I do think the bit about selectively loading the code used in the site would be rather interesting to experiment with. I guess there will be a certain limit of modularity after which the code would be too busy deciding which bit of the code to load but tracking down that limit should be worth a try..
Good luck
Thanks for the well-wishes, Omar.
PerformancePress decides which code to load through an htaccess file (intrepreting what content is being called via the URI), which means Apache will be doing the checking (in C++, of course) and possibly caching the results (if it’s done in httpd.ini); so the overhead is neglible.
first how r u all ?
then i want to know something abt how to hack a website
i am not gonna to use this in illegal way but i want to know how to active this work i gotta be mad !!
if u read my reply i will be happy if helped me !!
mail me pls L nighty_soft@hotmail.com or nighty_soft@yahoo.com
I would like to see this code bacome mature and released to general use. Also you may contact Matt@Wordpress and pass the ideas to see if it can be incorporated to the Official release of WP. Looking forward to good news.
Btw. I’m managing with Xcache & using ngix to serve static contents (while Apache handles php).