Linux & Unix

Linux filesystems are a moving target: each new kernel release can potentially alter their performance and reliability. So, its interesting to periodically measure filesystems performance. This time, I used the newly-released Fedora 17 (amd64 version, 3.4.x kernel branch). We already know the contenders:

• ext3, the classic Linux filesystem 
• ext4, the natural ext3 successor as default Linux filesystem 
• xfs, an high performance filesystem designed with scalability in mind 
• btrfs, the new, actively developed, feature-rich filesystem (which, recently, has been propesed as the new Linux default filesystem)

I am sure that you know Mysql quite well: this advanced, very used open source database is one of the key softwares behind the LAMP stack (Linux, Apache, MySQL, PHP). Sun (now Oracle) estimate that about 50% of all deployed databases are mysql installations.

Very often, these installations are kept at default settings – and for good reason: generally, default parameters are configured for safety and, if you don't really know what you are doing, you can severely impair your server reliability and/or performance. Moreover, many mysql installations deal with basic, simple tasks, where performance is not a crucial factor.

However, there are cases where you really need to speed up your mysql deployment: for example, think to a frequently visited web site with mysql backend, or an application that executes a lot of queries/transactions. In this case, what you can do to extract more speed from your beloved mysql server? This article will shed some light on this topic.

Almost one year passed from my latest all-around Linux filesystem comparison, and a lot of things changed. First, I discovered that, while Fedora documentation stated that ext3 write barriers were enabled by default, they were not correctly activated on my test setup. This inflated ext3 benchmarks in a unfair manner. Second, a lot of kernel development activity happened: xfs got some much-needed metadata handling speedup, btrfs saw intensive performance optimization and write barriers were replaced by FUAs [1].

I'm sure that I don't need to introduce you Joomla: this powerful, (more or less) user friendly CMS (content management system) is well known and widely used nowadays. It assists the user in quickly publishing its articles and news stories, while relieving him from some of the needed in-depth HTML and CSS knowledge. This sort of CMSs were, and are, a key factor for the “Web 2.0” revolution (whatever this term means for you!)

However, this great, added flexibility come with a cost: performance. Joomla and other free CMSs heavily use object-oriented PHP scripts, leading to quite high load on the hosting server. The net result is that while a cheap server machine can sustain thousands statics HTML pages and many hundreds “light” dynamic pages, the very same machine can find itself in troubles trying to provide more than few Joomla's pages.