[Melbourne-pm] An article on session storage in perl weekly newsletter

Toby Corkindale toby.corkindale at strategicdata.com.au
Mon Feb 17 17:53:29 PST 2014


Hi,
Did anyone else read the article (blog post) linked from the Perl Weekly 
on website sessions?

http://perlgeek.de/blog-en/misc/2014-running-a-public-website-sessions.html

I thought it was hopeless.
All the problems faced by the author were due to poor architecture or 
poor quality of Perl modules.

Obviously, the author not having su or sudo access to the user the site 
was running as, is a massive failure of competency. The site was running 
as Apache server-side-includes, which is about as old a design as you 
can have. Having to upload secret CGI scripts to the server so as to be 
able to have them run system() commands to clean out folders is 
ridiculous! (But I understand that if you're desperate and that's the 
only access you have, you'll make do with it..)

But beyond that -- the clear source of their problem was that they were 
running a web session module that:
* Created a file per session
* Never expired old sessions

The author mentions that the disk was filled by 3 million individual 
small session files. There were 100k individual visitors per month. Even 
if you kept sessions around for 30 days, that'd be a manageable 
quantity. It's pretty self-evident that if you never, ever expire 
sessions, then you'll run out of storage sooner or later.

The author's eventual solution was to move to 256 (!) individual sqlite 
databases for session storage, sharding the data set by the leading IP 
octet of visitors. (Using a single sqlite database gave rise to 
performance issues due to DB locking)

*sigh*

And I wonder if they've started expiring old sessions too, or not? (And 
thus just put the problem off for a bit longer)


Anyway, the point of all this was: Why are people (who are notable 
enough to get their blog posts re-shared widely) using such poor quality 
modules, and having to build workarounds for them?
(CGI::Session is the top hit on cpan)

It's helpful to hear how they solved it, but why did they have to? Every 
single person who builds a website will need to re-solve the problem. 
They shouldn't have to!

You get somewhat better quality modules if you use one of the Perl web 
stacks, Dancer, Catalyst, etc. However, even the standard session stores 
for Catalyst::Session::Store (File and DBI/DBIC) don't do automatic 
expiry as far as I can tell. (I didn't investigate Dancer or Mojolicious)

Why aren't we doing this stuff better on Perl?

OK, ending rant now.

-Toby


More information about the Melbourne-pm mailing list