perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tina Müller <>
Subject Re: Ways to scale a mod_perl site
Date Sat, 19 Sep 2009 18:43:31 GMT
Hash: SHA1

On Fri, 18 Sep 2009, Igor Chudov wrote:

> On Fri, Sep 18, 2009 at 10:13 AM, Tina Mueller <> wrote:
> > How does the user invalidate that "session"? (in case the cookie leaked
> > or something like that). Or how can the website owner log out a certain
> > user?
> >
> Same way you do with a table: when the user logs out, you update their
> cookie to a new one, where "userid" is not set.

That doesn't invalidate the cookie.
It resets the cookie in the browser, but the string itself is still a valid
session and can be reused.
Since there is nothing stored about it server side the server just gets
the session string from the client and doesn't care (doesn't know) if
any browser "logged out".

And storing the IP in the session wouldn't work for users that get a
new IP very often. On the other hand, several users might have the
same IP in the view of the server.

> > Is one select per request that bad? if the website is completely
> > dynamic you will probably have other requests as well?
> >
> >
> Well, the cookie table is the one that gets hit a lot and grows out of
> control. It is hard to scale and replicate. Storing cookies on the browsers
> solves this completely. I can have a billion browsers connect to my site and
> no database growth will occur from that.

You said your site is completely dynamic. So you probably have other
database requests per page view. This is the point where I would start
to optimize. IMHO that will bring you performance very fast.
On many pages of my portal, in the ideal case there is only one select
to the session table, all other things are cached (of course this
counts only for overview data and forum threads that were recently viewed,
but these are the pages which have the most views).

A session table is quite small and your selects always use an indexed
column. You might even be able to seperate the sessions into several
tables/databases (splitted by the first character of the sid, for
example), which enables you to split to different servers
without the tradeoff of replication.

- --
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Made with pgp4pine 1.76


View raw message