Session Save Handler

[Wayne Graham]

We're in the process of rolling out Omeka to a clustered environment.
Right now the switch (a BigIP F5) is persisting sessions to the
particular server node that initiates the request so that a user
initiates a request which is directed to server1, they will continue
to go to server1, which writes a session token in the php shared
location as expected. However, as the Zend documentation states
(http://framework.zend.com/manual/en/zend.session.introduction.html)

The default » ext/session save handler does not maintain this
association for server clusters under certain conditions because
session data are stored to the filesystem of the server that responded
to the request.

I was hoping there was an "easy" DB compatible session handler, but it
appears as though this is not configurable option in the code (without
some monkeypatching). Are there others out there that might need this
level of session handling? I have an idea on how to approach this, but
wanted to check to see if anyone else had tried it yet...

Wayne

[Kris Kelly]

For now there's no built-in solution for this, unfortunately. Looks like you've already figured out that you'll have to patch Omeka_Core_Resource_Session to use Zend_Session_SaveHandler_DbTable (http://framework.zend.com/manual/en/zend.session.savehandler.dbtable.html).

If you can get this working, send us a patch and we'll do our best to incorporate it in the next release. The patch itself seems relatively straightforward, though areas of discussion might include: whether or not to add a new database table to the default omeka schema, and what specifically should be configurable about this, i.e. whether to only toggle it on/off in the config or to allow more complicated configurations.

What do you think?

Kris

> --
> You received this message because you are subscribed to the Google Groups "Omeka Dev" group.
> To post to this group, send email to omek...@googlegroups.com.
> To unsubscribe from this group, send email to omeka-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/omeka-dev?hl=en.
>

[Wayne Graham]

Ok, turns out this is relatively straight-forward. What I was thinking
for the application/config/config.ini options are something along
these lines:

; Session handler. Valid options include default and database
session.save_handler = "database"

; define the save location. For file-based, uses full path; for
database, creates table
session.save_path = "sessions"

The actual data table is relatively straight forward, but it looks
like you can go really crazy. From what I saw from the session tokens,
nothing too crazy is going on right now, so I just used the following
(straight off Zend docs):

CREATE TABLE `sessions` (
`id` char(32),
`modified` int,
`lifetime` int,
`data` text,
PRIMARY KEY (`id`)
);

Thoughts?

Wayne


On Sep 20, 10:14 pm, Kris Kelly <kristopherbke...@gmail.com> wrote:
> For now there's no built-in solution for this, unfortunately.  Looks like you've already figured out that you'll have to patch Omeka_Core_Resource_Session to use Zend_Session_SaveHandler_DbTable (http://framework.zend.com/manual/en/zend.session.savehandler.dbtable....).

[John Flatness]

Hi Wayne,

We'd have to decide, I guess, whether to just have that table always exist for all Omeka installations, and just lie dormant for the majority that use the default save handler, or have some other process be required for people who want to use the database method.

We already (I believe), pass the application config when we set up Zend_Session, so some of this configuration may actually be possible now. Documentation for the config keys is buried somewhere in one of the Zend_Session manual pages. You may even be able to simply write a thin extension of Zend_Session_SaveHandler_DbTable that "knows" the table name and db options from the rest of Omeka. This way, I think you could then just specify the name of the session handler class in the config.ini.

Of course, we can also just, as it seems you're suggesting, have two (or more) pre-defined handler options, and a config setting that does the appropriate Zend_Session setup. While the above may be more general (if it actually works), this may be the preferable option, given the limited scope of options as far as Omeka/PHP session handlers go.

John

[Wayne Graham]

I'll through this out there, but maybe the database-based session
handler should be the default. I'm thinking of all the installs on
shared hosts where all the sessions are getting written to the same
directory (I'm thinking Dreamhost, etc). It may make more sense to
default to the database save handler for these people (who will not be
getting in to this level of the code) so they can benefit from the
small performance boost (and some argue, at least back-in-the-day, the
improved security, at least with things like session fixation from
another site) of the database save handler.

Anyway, I thought I'd open that can of worms...

Wayne

[Kris Kelly]

Interesting idea. Does it always provide a performance boost, or would it depend on the user's MySQL setup?

I'm automatically inclined to stick with the simplest default solution for sessions in PHP, i.e. the filesystem, but as most know by now, sometimes the defaults for PHP are just awful and insecure.

What do others think?

Kris

[Wayne Graham]

It's always hard to quantify a performance boost without running some
benchmarks in different scenarios (kind of hard to replication a high-
traffic setup on my laptop). With most hosted solutions, it'll depend
on the disk array, raid level, load balancing, disk speed, disk
controllers, disk attachment, and network connection which vary
wildly. From what I've seen, there's not a lot of info being stored in
the session data, so fwrite will go directly to memory to get flushed
to disk. If you're on a dedicated machine, the fwrite will always be
faster, but I suspect the vast majority of these installs will be on
clustered machines or shared installs in which the db writer will be
more efficient. Beyond that, using memcached would be the next tool to
break out...

Anyway, do you (@omeka) have any stats on where people are hosting
Omeka? I know I see a lot of sites on Dreamhost, but is there some
type of breakdown?

Wayne

[Kris Kelly]

Good question. We don't have anything in Omeka that pings the mothership when a new installation goes live, so to the best of my knowledge there is no statistical breakdown.

We do recommend Dreamhost, Bluehost and Webfaction, so there would likely be more on those hosts.

Kris