Forum: Rails deployment Still, big session problem

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
11333f97a96662abe5d1e44fe1adf372?d=identicon&s=25 jcontonio (Guest)
on 2007-04-16 15:22
(Received via mailing list)
I am still having a rather bad sesssion problem on my production
server.

/tmp is getting loaded with ruby_sess files and eventually (probably
takes 2 weeks) crashes out my application. Can someone point me to an
article that better explains how to deal with file based sessions? Or
should I just be running a cron job?
2e8a8696351166c63ac462f780ec3b5c?d=identicon&s=25 Mike Sax (Guest)
on 2007-04-16 18:45
(Received via mailing list)
I would highly recommend switching to ActiveRecordStore for keeping
track of your sessions. You'll still have to periodically delete
sessions, but it's easy to do, and much more efficient (and scalable)
than file-based sessions.

    http://wiki.rubyonrails.com/rails/pages/HowtoChang...
D1f1c20467562fc1d8c8aa0d328def62?d=identicon&s=25 Florian Gilcher (skade)
on 2007-04-16 19:48
Depending on the database, ActiveRecordStore is a bad idea. Especially
when using a database that does not support row level locking (like
MyISAM tables in MySQL-databases), constant concurrent reads and writes
are a problem. In my opinion, the place for these large, small and
potentially unstructures datasets is eighter the file system or memory.
(thus, memcached or pstore)

If you do not have any problems with session performance, it might be
wise to just set up a hourly cronjob that sweeps all files older than 15
minutes (or whatever your session length is set to) inside your
temp-directory.
11333f97a96662abe5d1e44fe1adf372?d=identicon&s=25 jcontonio (Guest)
on 2007-04-16 20:00
(Received via mailing list)
Mike,

Just switched over. Thank you for that suggestion, it was so easy!

I should clear the table data every now and then right?
11333f97a96662abe5d1e44fe1adf372?d=identicon&s=25 jcontonio (Guest)
on 2007-04-16 20:03
(Received via mailing list)
Hopefully this sparks a debate then because having run into my file
based session problem, I'd like to know what are the cons of
ActiveRecordStore. All I know is, 50,000 ruby_sess files taking down
my app aren't good.

On Apr 16, 1:48 pm, Florian Gilcher <ruby-forum-incom...@andreas-
D1f1c20467562fc1d8c8aa0d328def62?d=identicon&s=25 Florian Gilcher (skade)
on 2007-04-16 20:24
jcontonio wrote:
> Hopefully this sparks a debate then because having run into my file
> based session problem, I'd like to know what are the cons of
> ActiveRecordStore. All I know is, 50,000 ruby_sess files taking down
> my app aren't good.
>
> On Apr 16, 1:48 pm, Florian Gilcher <ruby-forum-incom...@andreas-

Thats a problem that could also be solved by dividing sessions in
multiple folders (take numbers and search your folders). The main
Problem of pstore is that it spams one folder - a scenario that files
systems are not build for. They may allow it, but they can't handle it
very well. A more intelligent storage could cope with that. BTW, thats a
similar idea as in partitioning tables for better write performance on
tables with table locking. If your system can't handle your set,
partition it. (or clean up regularily, as i suggested above)

As for cons against DB based store: as i mentioned before, it's
performance is not database-agnostic, while pstore and memcached
performance pretty much behaves the same on most system. It suffers from
many concurrent hits on your database while filesystems are better
designed to handle such tasks. Another thought is that volatile data
like the session can be kept memcached, as in case of something really
nasty happening, your sessions will likely be invalid anyway.

On the other hand: these are thoughts are for final optimization. As you
needed a quick fix, ActiveRecordStore is perhaps not that bad ;).
30b3f6355fad8461e37de7891753d810?d=identicon&s=25 John Leach (Guest)
on 2007-04-18 16:13
(Received via mailing list)
Hi,

The Reiser 3 file system was built to handle millions of files in a
directory effortlessly.  And, unlike many other file systems, it is
space efficient with tiny files like this.  If you're using Linux, then
this is a good solution for your session storage. (though perhaps more
difficult to retroactively fit :).

Ext3 now has directory hashing too, but I don't think it's enabled by
default, and I've not tested it's performance.

Looking at the FileStore code though (from actionpark 1.13.3, it cannot
be trusted to atomically update fragments in a multi-process setup
(though it seems to be thread safe).  This means you could conceivably
read a fragment as another process is writing to it, and get a broken
session object or corrupted cache fragment.

If you're using an OS with an atomic rename system call (like Linux, and
probably any UNIX) then you could tweak the FileStore code to avoid the
race.  If not, and you still want to use FileStore, then I'd recommend
using one FileStore object over drb.

If you store sessions in memcached, bear in mind that when its ram pool
fills it will automatically expire entries that have been used the least
recently.

This might be more detail than is necessary for the original poster, but
maybe it's useful to someone.

John.

On Mon, 2007-04-16 at 20:24 +0200, Florian Gilcher wrote:
> Thats a problem that could also be solved by dividing sessions in
> multiple folders (take numbers and search your folders). The main
> Problem of pstore is that it spams one folder - a scenario that files
> systems are not build for.

> As for cons against DB based store: as i mentioned before, it's
> performance is not database-agnostic, while pstore and memcached

--
http://johnleach.co.uk
--
http://johnleach.co.uk
Df5e7adb20adae6c120b04e7cafb15a0?d=identicon&s=25 Rob Sanheim (rsanheim)
on 2007-09-25 23:03
(Received via mailing list)
On 4/16/07, jcontonio <jcontonio@gmail.com> wrote:
>
>
> Rob,
>
> Thanks for the help. Any idea how this works on a FreeBSD system? The
> find command is kinda different here.
>
> A for the link on that page to the Ruby way of doing things, it's
> rather confusing where to put that.

Sorry, I don't know with FreeBSD.

- Rob
Df5e7adb20adae6c120b04e7cafb15a0?d=identicon&s=25 Rob Sanheim (rsanheim)
on 2007-09-25 23:05
(Received via mailing list)
On 4/16/07, Rob Sanheim <rsanheim@seekingalpha.com> wrote:
> Just run a cron job.
>
> Here's one way:
> http://www.realityforge.org/articles/2006/03/01/re...
>
> - rob

Actually that was for AR sessions - here's a method for file sessions:

http://www.missiondata.com/blog/?p=58

- Rob
11333f97a96662abe5d1e44fe1adf372?d=identicon&s=25 jcontonio (Guest)
on 2007-09-25 23:05
(Received via mailing list)
Rob,

Thanks for the help. Any idea how this works on a FreeBSD system? The
find command is kinda different here.

A for the link on that page to the Ruby way of doing things, it's
rather confusing where to put that.
4375b4aca04b8d72482fd409fb6d0b47?d=identicon&s=25 Roderick van Domburg (roderickvd)
on 2007-10-02 11:31
Rails 2.0 features a hashed cookie-based session store by default, which
is the best performer and is highly recommended as long as you keep your
session size below 4 KB or so.

--
Roderick van Domburg
http://www.nedforce.com
This topic is locked and can not be replied to.