To provide features like login or persistence to the user, stateless protocols like HTTP depend heavily on sessions. Almost every web application is using it.
An easy job you would say? Of course! But what about high availability setups with hundreds of concurrent users? And sessions need to be shared between application servers so that that users do not lose their current login session.
RT’s vanilla way is to put this in MySQL which produces queries on every request. Second bad thing is the created GET_LOCK query which slows down the environment after a while.
Better way is to use files because file sessions are extremely fast. No network overhead and not greatly influenced by differential IO. But then you have to share sessions between application servers and you should say good bye to that idea because we do not live in an ideal world and shared file systems are terribly slow.
I opt for Redis. Meanwhile available on every system, fast as the LHC in Geneva and rock-solid like carbon. Redis is so adorable simple that you only can fall in love with this single-core-minimal-footprint-key-value-store thingy. But I’ll stop hallowing now.
# Annouce Redis to RequestTracker Set($WebSessionClass, "Apache::Session::Redis"); # Single server Set(%WebSessionProperties, server => '127.0.0.1:6379' ); # Sentinel Set(%WebSessionProperties, sentinels => [ '127.0.0.1:26379' ], service => 'mymaster', sentinels_cnx_timeout => 0.1, sentinels_read_timeout => 1, sentinels_write_timeout => 1 );
You can find more information in the product documentation.
It’s just a glimpse, but there a lot of ways to bring RequestTracker to enterprise level with more than 300 concurrent users and millions of tickets and attachments. Of course, highly available and scaled in every direction. You only need to ask us how to do!