But again I'd guess in most cases that ID is stored in DB file(s)
and looked up on each request, not in memory.
Maintaining session is something all web-application developers have to
deal with. One way or another you're rehydrating some session data on
every request, that's how you can determine user access and control. The
difference is where you store that session data. I'm aware of three
options for storing session data, and each has its advantages and
disadvantages. They are: In-process (memory), out of process (but still
memory), and in a DB. Roughly speaking they're listed in fastest (but
least secure) to slowest (but most secure).
In process: Storing session in memory is damn fast! No DB is going to
have faster IO than the in-memory access to session data I'd have on a
web server. Plus, I can store full objects in memory, I don't have to
serialize them. The obvious disadvantage to memory is that it's a finite
resource, and if the machine goes down I lose that memory, so I lose
those sessions. The other more subtle problem w/in-memory is that your
session is tied to a specific web server. If I'm in a load-balanced
setup I need to make sure I have server-affinity so each request goes to
the right web server since the web servers own the session individually.
Out of process: This is a variation on the first, where I basically lift
the session storage off the web server, and put in onto a second system.
But on this second system the session is still stored in memory. I've
added network overhead to the session retrieval, but I don't have any
disk IO. This machine could be a single machine w/lots of memory or
could be a network of machines running something like memcached. I've
lost the ability to store objects directly as they need to be serialized
across the wire, but I'm still running at memory speeds for the
retrieval. Plus I don't need server-affinity any longer since any web
server can retrieve the session info. Of course, you'll need to be
careful if two requests for the same session hit at the same time.
In DB: This is by far the slowest option. Not only do I have to
serialize and transmit session data across the wire, but I need to write
it into a database, and databases have huge overhead, but you gain the
ACID nature of databases from that overhead. This is clearly the most
"secure" of the options since you are almost guaranteed not to lose
session, but you'll pay a performance price. Like out-of-process you do
gain the ability to service each request from any web server though.
Unfortunately developers don't think about this option though, and I've
seen cases where a developer stored something "in session" to avoid
going to the DB because it was slower to go to the DB. Not only is that
likely a pre-mature optimization (measure!) but guess what, what session
in db, he was going to the DB anyway! :-) Session in DB can add a huge
overhead to DB load too.
-Walden
midrange.com
