[Gluster-users] another look at high concurrency and cpu usage

[Arvids Godjuks]

There is two ways how to store sessions in memcache:
1). Application has a session object for working with session data or
just users memcache directly.
2). Use php.ini magic: http://php.net/manual/en/book.memcached.php -
it has session locking and is transparent - you continue just to use
$_SESSION variable. No change from the application side is needed.
Also search on how to do the redundancy in case one memcache server
dies so you don't lose any data. Also memcachedb can be used, it has a
permanent storage capability.

Why problems? It's simple. You lock the file, read it, write it when
you session is closed by script, unlock. All that needs to be done
over the network. + all clients have to check if the file is locked or
not, so concurrent access will be quite slow. Maybe I'm overreacting,
but it read-write intensive load, almost 1:1 in nature and session
files are small. So you have to read and write a lot of small files
from and to your gluster fs. Don't forget the replicate overhead. And
replication is synchronous, that will definitely add to the lock time.
Maybe that's why you get high CPU usage. Many many small operations *
replicas = i/o load.


2010/2/16 John Madden <jmadden at ivytech.edu>:
>> Storing PHP sessions on Gluster FS really isn't a good option, because
>> session file is locked while scripts access it. You will definetly hit
>> a performance issue. My advice is to setup a memcached server and use
>> memcache (or memcached) PHP module's ability to store session data in
>> memcache server. It has the capability to provide a fault-tolerant
>> service if you setup a few memcached servers. And it's lightning fast.
>
> Interesting.  I had actually used memcache sessions before but the app
> doesn't work with them so I had to fall back to file-based sessions. Why
> does locking cause such problems?  It works quite well on NFS.
>
> John
>
>
>
>
> --
> John Madden
> Sr UNIX Systems Engineer
> Ivy Tech Community College of Indiana
> jmadden at ivytech.edu
>