LightPress

I have started to check-in some larger changes in svn to prepare for a serious 2.0 release. Most of these features we are already using successfully in our blog network weblogssl for a few weeks (+-30 blogs, almost 1.000.000 pageviews per day).

We are planning to release Lightpress 2.0 with the following features:

Openid comments:We already have this running in our branch, and we are using it already in some of our blogs. (f.e. www.genciencia.com). What is missing here is the adaptation of the templates in the trunk, and some generalization of settings which are now very specific for our setup.

Improved caching: Here we have have seperate caching of elements of the page. F.e. the sidebar is cached seperately from the body page, so that we can have very long expiries on the post pages, only occassionally decaching them on a new comment or trackback. This is also already in our branch and seems to be working correctly.

WP 2.1 compatibility
Various smaller things: performances fixes, better UTF8 support for tags, improvements to Comment Spam handling, SEO

I have started committing the openid stuff in svn, and I still have to find a way to bring over the caching without breaking too many already existing installations.

The most trafficked blogs powered by LightPress are those published by the Italian nanopublishing company Blogo, which I helped found last year and later left. The 15 blogs are housed on an old Celeron 900, and backed by a dual-Xeon MySQL server which is mostly sitting idle thanks to our caching module.

In September, the old Celeron served 2.25 million page views, with a peak rate of 250 page views per minute on September 26 at 11:04:00. If you take into account that every page view involves several image hits (~10), at least one adserver hit (hosted on the same machine), and one stats logging hit (same machine, again), all of them served by a fat Apache, LightPress seems to handle itself pretty well under load.

As much as I like the concept of WP "pages", which should enable the use of WP as a lightweight CMS with built-in blogging, I do not think it is currently usable for anything more than very small personal sites. The problem is (again) in the liberal use that WP does of MySQL resources, and in the bad design of its DB layout.

I just finished inserting a couple of hundred pages in the db to move a site which is currently using a custom CMS to WP+LP, and imagine my surprise when trying to access "Manage Pages" in the WP admin console PHP exited with a

error. I raised

to 24M, restarted Apache, and......waited 25 seconds for the page to load!

As promised a couple of days ago, today I have spent half
an hour on the SQL queries emitted by a default WP installation. To do
so, I have logged the quries in mysql and written a simple PHP test
script. Here is the first run of the script, comparing 500 runs of
each of WP's and LP's queries (LP is missing two queries, one for
users as I have not enabled Jerome's AdminOptions plugin, and one for
static pages as they are not emitted by default):

WP queries
----------
1. users:                       0.090523 ms
2. options:                     0.118955 ms
3. posts:                       0.222328 ms
4. posts (count):               0.049981 ms
5. posts (categories):          0.190947 ms
6. posts (comments):            0.100817 ms
7. posts (meta):                0.053948 ms
8. categories (flat):           0.138303 ms
9. categories (flat, again):    0.137282 ms
10. categories (posts count):   0.125479 ms
11. archives:                   0.060956 ms
12. archives (again):           0.063106 ms
13. static pages:               0.086774 ms
14. link categories:            0.073251 ms
15. links (first category):     0.262116 ms
16. links (second category):    0.289843 ms
total:                          2.064609 ms

LP queries
----------
1. posts:                       0.192770 ms
2. posts (count):               0.049936 ms
3. posts (comments):            0.056783 ms
4. posts (categories):          0.190775 ms
5. categories:                  0.168887 ms
6. archives:                    0.062130 ms
7. links:                       0.085729 ms
total:                          0.807010 ms

After the WP/MySQL discussion of a couple of days ago, I have taken a few minutes today to set up a test envornment with WP and Lightpress, configured with the same exact features and running against the same DB taken from a 1k posts production site.

I have then logged all queries sent to MySQL (

) by the index page of the two frontends, and written a quick script to benchmark each statement after having primed it a few times to make sure table data is in memory. The results are pretty much what I expected (citing from memory as I don't have the test environment on my laptop): WP runs 16 or 17 queries against LP's 7 queries, and LP is faster by an order of magnitude.

I hope to be able to post a detailed analysis soon, and maybe a few suggestions on how to improve WP queries without changing their nature, as I have no patience to delve into WP's code, and I would end up with something very similar to what LP is already doing.

If you want to see the WordPress community's own kind of FUD at work, have a look at the answers to this WP support topic (a questioned originated on Textdrive's forum). A few gems, and a few interesting insights on the inner workings of a relational (R as in InnoDB) database.

As far as I can tell, WordPress is better than most tools when it comes to performance.


I lack words to tell you how much I hate MySQL, its pathetic features, and its pathetic performance.

Accessible by date order does not mean that they are added to the table top. More likely the bottom I would think.

performance-wise, you should be comparing how the DB handles a bunch of immensily complex stored procedures.

MySQL is a very fine piece of technology and a very fast database, the same cannot be said for WP's code (see also this), db design and queries. For simple things (INSERTS and SELECTS) MySQL often beats the big names hands down (and yes, I have direct experience at work dealing with a 1million rows a day app).

Post formatting is fairly basic in LightPress and caters to the "what you type is what you get" crowd. But it's easy to expand LP's formatting abilities by using the PreFormatted 2.0 plugin.

Normally WordPress formats posts only when they're displayed (wasting rendering time and server capacity in the process). The PreFormatted plugin rearranges formatting plugins like Markdown and Textile so that they're only active in the backend, saving a formatted copy of the post to the database. If you use this plugin in the WordPress backend then the formatted data is available to your LightPress site.

Sencer has released a second round of benchmark results comparing WordPress, TextPattern, Serendipity and LightPress. I'm happy to report that LightPress continues to lead the pack at almost twice the speed of TxP and over three times the speed of WP. Memory usage isn't too shabby either.

This is without caching of course, since we have yet to add this feature to LP. A caching plugin is in the works and once it's available I hope we can get included in the second column as well.

If you're wondering whether or not to switch to LightPress, Sencer writes:

If you are a Wordpress user, the only reason for not using the Lightpress frontend is maybe certain plugins (though some are supported in lp) or if you don’t know any html and like the many ready-made templates for Wordpress (lp uses a different, IMHO easier templating system). Both of these points may change in the future.

I seems like LightPress (Luca suggested the new name since WordPress Fast Frontend was too long) is the fastest blog engine -- ehm front-end -- written in PHP. I am writing documentation for the first stable release, expect it to happen sometime soon.