[horde] Mysql session handling

Rick Irvine irvine at purdue.edu
Fri Oct 18 08:22:42 PDT 2002


On Fri, 18 Oct 2002, Roddy Strachan wrote:

> Date: Fri, 18 Oct 2002 16:50:32 +1000
> From: Roddy Strachan <roddy at netspace.net.au>
> To: horde at lists.horde.org
> Subject: [horde] Mysql session handling
> 
> Hi,
> 
> I am using Horde 2.1 and Imp 3.1  I was wondering if anyone out there has
> created a mysql function to store the session variables.
> 
> I have used the 'mm'; module but finds that it keeps segfaulting every so
> often, I am currently using 'files' but of course it fills the drive up.
> 
> Any ideas or pointers would be appreciated.
> 
> 
> ---
> Cheers,
> 
> Roddy Strachan.

I presently am running Horde/Imp/Turba with a MySQL session handler on a
cluster of small Linux machines (using Linux's IPVS, IP Virtual Server).  I
started with the MySQL session handler from www.phpbuilder.com.  Just click
on the "Show All" under the article list on the main page, then click on
"Appliation Architecture", then "Session Management", then "Custom Session
Handlers in PHP4".  You will find an article there written by Ying Zhang.
I've modified mine a bit over time, but Ying's is a very good start in my
opinion.

The one way in particular that mine differs from Ying's is that instead of
having one sessions table, I have 36.  I found that even at 1% probability
of calling the cleanup function I had too many locking attempts on the
single table.  With 6 nodes all at about 100-125 apache processes
constantly, MySQL could still bog down.

So I split it into "sessionsa" through "sessionsz", and "sessions0" through
"sessions9", then pulled the first character from the session ID to tack onto
the name of "sessions" to see where it should go.  This splits the locks
across 36 tables instead of just one.

Now, presently my GC function still locks all 36, but that I am hoping to
rewrite today.  (It's still faster w/36 than w/1.)  Instead, it will randomly
pick one table and GC it.  By random distribution, it should hit all the
tables evenly and often enough to keep them from getting too big.  (I just
put this cluster up last week, so I am still brushing off the rough spots.)

I would love to see this properly built into horde itself, but I am no php
guru and am still flooded with work on maintaining my cluster.  It'll be
months before I can do any more efforts on R&D, much less contributing a
proper MySQL session handler to horde.  :(

If you want to stick with files (which would be faster IMHO), you can set
up a scheduled job to delete the ones that are older than some set time.
My old single-server setup was with files, and I had a cron job delete the
ones older than 24 hours.

- Rick



More information about the horde mailing list