Peter Rundle wrote:
Hi Justin,
Thanks for your input. (thanks to the others also but Justin has some
direct questions which I'm attempting to answer).
RE:
using a database is the most common way to solve this.
That seems to be the message I'm getting. I am in a position to write
my own session handler, and this is something that I have considered,
but rather than rush in and re-invent the wheel thought I'd do some
research first.
But I do feel at this point that using the database to hold the
session is the best idea. In order to achieve redundancy in the
future, one has to fix the database replication problem in any case,
so putting the session in the database doesn't add to the complexity
of that problem. Putting the session information on the web /
application server however does. I accept that PHP sessions have
their place, but in a large 24 x7 environment it immediately ties the
user to a specific server. Solutions that then attempt to fix that by
getting into the network layer and sending the user back to the same
server or copying the session information between web servers are just
patching up on an initial bad technology decision. Better to just add
it to the database issue and then figure out how to replicate the
database which is a problem I have to solve in the long term anyway.
There are pre-baked database backends for sessions in PHP, I believe
they are included in the core you just need to tell php to use it.
Personally I would try to stop using the sessions, and store the client
data in the cookie (assuming its not too heavy)
your servers are then just a pool of state machines. You can yank any at
any time with no loss of service (assuming you take it out of the load
balancer first)
this is a bit unclear to me. do you want real sync between multiple
dbs, so the data is always consistent or just fail-over?
I have installed and configured an Oracle system in the past that had
multiple web servers fronting dual database servers that where
configured as multimaster with two phase commit etc and know that it
can work but also understand the "pain" in that equation. This is for
the future though and may never happen, depends on how successful the
site is.
can you give us any more general info about the setup?
Well it's your classic LAMP web site right down to the part of using
PHPS's Mysql specific database functions embedded within the pages
that contain the Html. This is something that I'm slowly fixing by
removing all the sql code from the html pages and placing it into data
classes. I'm also abstracting the sql functions so that I can get
adodb in there and thus use prepared statements, or change to
Postgresql, Oracle (insert latest favorite rdbms here).
I know its the "best" way of doing it but that's never appealed to me
for PHP, PHP's object orientation and the like have always struck me as
hacked on, and cludging it into the traditional 3 tier system just seems
to create work rather than save time down the track. I mix my php and
html and I'm proud of it ;->
I split off into include files commonly used functions and the like but
to me PHP is about presenting stuff, It seems silly to have wrappers all
over the place.
However this is not something that I have to fix right away, it's a
decision about which direction to head in. If all goes well the site
"may" grow to be more than what can be handled by one server but also
it's a 24x7 environment and scheduled outages to upgrade hardware /
software etc, won't be an acceptable outcome. Unscheduled outages
would also be bad, but one does live in the real world and servers do
crash. However failing to plan for hardware/software infrastructure
futures is not showing due diligence. With "cloud" computing,
virutalisation, snap shots and fail overs, the options for redundancy
and fail over are much greater these days. So I'm at the "researching
the options" stage. No plans to move away from Linux though ;-)
Yeah you just need to look at where you introduce the next bottleneck
with that, If you can the "best" option is usually to have your writes
going to one location and then accept reads from another. As most
activity on most pages is read intensive you can have your mysql set up
with a small pool of multi-master replication or a cluster, and your
writes go to there, those are master > slave replicated out to either
each web server or a distribution server, so all the heavy duty queries
get done on those rather than slowing up your database with writes.
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
