Session Stickiness…A thing of the past

So ever notice some old sites with domains showing up in your address bar that look something like www1.example.com or www2.example.com? This is usually because the site owners are trying to load balance, in a crude way by making you stick to one particular webserver.

Usually the main reason for doing this is because of sessions. For security reasons your browser will not keep you signed in with the same session if you hop subdomains. What this means is that if you logged in on www1.example.com and now go to www2.example.com the browser will consider this as two separate sites and you would have to login again on www2.

People used to play a number of tricks to remove session stickiness such as storing sessions in the db so that they could transparently load balance your session across multiple webservers. However databases due to their inherent nature are often large monolithic beasts that are much slower than some of the alternatives available out there now.

One of these, which I am a fan of, is memcache! The folks over at danga.com have given us one of the most powerful building blocks for creating highly scalable websites.

We can now experience load balancing as it was meant to be!

As an example lets take PHP session handling. PHP usually stores its session on the local hard drive of a server. You can also make it store sessions inside a database, lets say MySQL. However, as I mentioned earlier MySQL is very slow compared to memcache and is inherently harder to scale compared to memcache.

To setup PHP to use memcache for sessions, this is all you have to do :

0 - Install memcache library available at http://pecl.php.net/package/memcache

1 - Open php.ini

2 - Set session.save_handler = memcache

3 - Set session.save_path = “tcp://IP:PORT&weight=X” where X is the weight of a particular memcache server. You can add as many as you like by specifying one after the other separated by a comma.

4 - Install memcached. For a distribution like Fedora or CentOS just execute “yum install memcached”

All of this should not take you more than 5 minutes, and you are done!

Now to scale just keep adding more servers and firing up the memcached daemon  and experience the true beauty of completely transparent load balancing :).

mysqlnd

The new PHP driver for MySQL is out! http://dev.mysql.com/downloads/connector/php-mysqlnd/
Anyone give it a whirl?

Well we certainly did and its cool :).

You can read all about it by clicking the link at above. I especially like the stats that the new driver now presents to you.

Here is a sample

bytes_sent 68935
bytes_received 304237
packets_sent 1229
packets_received 4427
protocol_overhead_in 17708
protocol_overhead_out 4916
result_set_queries 199
non_result_set_queries 21
no_index_used 65
bad_index_used 0
buffered_sets 198
unbuffered_sets 0
ps_buffered_sets 0
ps_unbuffered_sets 1
flushed_normal_sets 0
flushed_ps_sets 1
rows_fetched_from_server 609
rows_fetched_from_client 609
rows_skipped 0
copy_on_write_saved 4895
copy_on_write_performed 4168
command_buffer_too_small 0
connect_success 401
connect_failure 0
connection_reused 0
explicit_close 401
implicit_close 0
disconnect_close 0
in_middle_of_command_close 1
explicit_free_result 1
implicit_free_result 198
explicit_stmt_close 1
implicit_stmt_close 0
Persistent cache enabled
put_hits 8
put_misses 10
get_hits 18
get_misses 9045
size 10
free_items 0
references 2

Although they says its beta in all our tests it seemed pretty stable.

include file mystery

Whats faster ?
1 - include
2 - include_once
3 - require_once

When I benchmarked our application the php execution time was smallest with include.

That seems to make sense since in the other two options php has to check if the file was included previously or not.

However, we also found significant differences between include_once and require_once. Anyone care to shed some light on why that was happening?

FYI our version of php uses x-cache. I wonder if that has anything to do with it.

MySQL Optimizations on Linux

It is important to optimize all pieces of the LAMP acronym and MySQL is not exception to the rule when deploying on the live servers

Here be the compile time flags.

export CFLAGS=”-O3 -march=cpu -pipe -msse2 -m3dnow -fomit-frame-pointer -mtune=cpu” CXX=gcc CXXFLAGS=”-O3 -cpu -felide-constructors -fno-exceptions -fno-rtti”

As mentioned in my previous entry you can go check the GCC Manual pages to replace the cpu keyword in the mtune and march in the CFLAGS and the -cpu in the CXXFLAGS.

I got approximately a 5% performance boost with these during benchmarking.

Please note though that the developer team got a much bigger increase in performance when they optimized the tables by adding indexes and improving their queries.

In general we also found that a simple select query took about twice as much time when the table was using InnoDB compared to MyISAM.

I am open to any additional feedback and ideas anyone may have.

Linux hard drive performance optimization

Everywhere on the web I read about using the hdparm utility to increase hard drive speed. However it seems that this utility does not support sata drives properly.

I have access to at least 5 different machines that run linux with different sata hard drives but the hdparm command fails more or less on each one of them.

Here is the command I have tried in various places.

hdparm -d1 -c3 -u1 /dev/hda

and I always get errors like

setting 32-bit IO_support flag to 3
HDIO_SET_32BIT failed: Invalid argument
setting unmaskirq to 1 (on)
HDIO_SET_UNMASKINTR failed: Inappropriate ioctl for device
setting using_dma to 1 (on)
HDIO_SET_DMA failed: Inappropriate ioctl for device
IO_support = 0 (default 16-bit)

What I do not understand is that SATA drives have been around for quite some time. So whats the holdup ? Why does this not work?

PHP Optimizations

Anyone ever try and optimize PHP recently?

The following settings worked really well for me

1 - export CFLAGS=”-march=cpu -O3 -pipe -msse2 -m3dnow -fomit-frame-pointer -mtune=cpu”

Based on whatever processor architecture you were using you should then replace the cpu in the above line with the name of the processor as described in GCC Manual

2 - Try configuring with the following flags added: –enable-inline-optimization

3 - Once compiled use strip to reduce the PHP binary size like so -> strip php-cgi

4 - For a significant performance boost I would recommend the installation of an opcode cache such as x-cache. If you don’t know what an opcode cacher is or does go here

The above mentioned optimizations led to more than 50% increase in speed and a more than 50% drop in cpu usage. Please feel free to make additional suggestions on how I can squeeze more performance  out !

Cheers