The Yii Framework- one to watch

Posted on | December 2, 2008 | No Comments

There is a kind of descendant of the PRADO framework in the making, dubbed Yii.

A quote from Charlie Xue, PRADO founder:

Since 2008, the developer team of PRADO has shifted focus to developing Yii. PRADO will continue to be maintained and some features of Yii will be back-ported to PRADO.

As mentioned here, they take and incorporate ideas from PRADO (of course), Rails, jQuery, Symfony and even Joomla. This is one to watch, as PRADO has won several contests and it’s one of the frameworks which keeps a close eye on performance.

The Birth of Enterprise PHP

Posted on | December 1, 2008 | No Comments

You here and read things like this:

PHP is ready for the enterprise

almost daily the last few months. I have some second thoughts on this: I don’t think PHP is ready for the enterprise right now, in my opinion this was allready the case when PHP 5 was released (2004) and maybe even before that. Yahoo! adopted PHP for major development tracks in 2002. They were ‘enterprise’ sized at that time if I remember correctly.

Maybe it is the other way around: enterprises are ready for PHP. On the customer side: companies are opening up for Open Source technology for a while now, even the beloved Java has gone Open Source. And even more important, we are ready for Enterprise demands on the supply side too. In general, companies focusing on delivering solutions based on PHP are getting better organised, deliver better quality products and grow in size themselves. That’s why, in my opinion, we hear that mantra more and more the last 12 months.

Drupal performance tuning

Posted on | December 1, 2008 | No Comments

This won’t be the last post about Drupal performance tuning I guess.

Some steps you can follow to increase the performance of your Drupal-based website (if you need so), in no particular order:

Don’t let the database handle the cache

• Add memcache support (no surprise there): Install memcached on your server (or on a few of them). On Debian just do:

  1	<em>apt-get install memcached libevent

  and configure the daemon through editing /etc/memcached.conf. Also install the Drupal memcache module. Don’t forget to properly activate it and read the included README.txt file first. You’ll have to apply a patch to some core files if you want a fallback option to the database cache. Add the necessary info pointing to the memcache cache.inc replacement file in your settings.php file. Example from the included docs:

  1 2 3 4 5 6 7 8 9 10 11

  $conf = array(     'cache_inc' => './sites/all/modules/memcache/memcache.inc',     'memcache_servers' => array(                     'localhost:11211' => 'default',                     'localhost:11212' => 'pages'                     ),     'memcache_bins' => array(                     'cache' => 'default',                     'cache_page' => 'pages'                     ), );

• Do some static file-based caching (most of the time only usable for anonymous users). You can store these files on a ramdisk for better performance.
• Serve some of the pages to logged in users as if they were anonymous users. This could be done by handling the login and active user information through AJAX trickery.
• Serve anonymous users pages from cache using a module like Boost.

Don’t let the database handle sessions

• If you have only 1 frontend webserver, use file-based session handling (but you’re probably not on 1 server if you are in the need of tuning performance). This is the default for PHP, Drupal overrides this by defining its own session handlers. You could disable this by editing (and commenting out) the includes/session.inc file.
• As an alternative: use memcached based session handling. The memcache module has an example memcache-session.inc file you can use instead of the original one. Just copy it over the original includes/session.inc (take a backup first) and give it a try. You have to define memcached servers to connect to in your settings.php $conf array.
• Another possibility: use Sharedance. It’s nice, it works, no hassle. The only thing is, there is no session handler written for Drupal to handle Sharedance based session storage. The memcache-session.inc file included in the memcache module might be a good starting point for this.

And some random tips

• log and analyze slow queries. This is very important. It takes some time but it’s worth it. Learn how to use explain. A primer for this can be found here. Tune MySQL server settings (1,2,3,and more). Eventually throw in MySQL Proxy and read-write split (read from slave, write to master).
• use a reverse proxy or a CDN to store your assets. If Apache is your webserver used for serving your Drupal site, this will free a lot of resources for dynamic content handling (read: PHP).
• tune Apache and analyze the Apache error logs. 404 errors are handled by Drupal, reduce them lower their impact.
• Look at alternatives for serving your assets (images, files, css, …): nginx, lighttpd or maybe even tux are very good at this. You could even run them on the same webserver if you have no spare machines and they will still take some load of your Apache server.

More to come ….