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)
Yes I agree, I think this is the best solution as the application has so many queries to do on the database in any case before it
presents any pages I hardly think that the minimal data stored in the session is worth any speed saving. Then it doesn't matter
which server you hit for the "next query".
If the load balancer is worth anything at all it will auto detect that the server is not there and remove it from the pool
automatically. If you have a load balancer that doesn't do this, get a new one.
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.
LOL,
I mix my html and php too and agree that that is the whole point of PHP it's a template markup language, but I don't put Mysql
specific syntax SQL statements in there too, as I think that is bad practice. Better to do
<span>Name:</span><span><?=$member->getName()?></span>
and $member->getName can get the name value from the database (or the member class can have pre-fetched it and just return the
variable contents. Then when you have to restructure your database because you got the entity relationship wrong you only have to
change the member->getName method. Also there is good value in using prepared statements such as
("select name from member where id = ?", array(this->id));
And these I put in the member data class thus the same php code can run on a
mysql database or a postgresql.
> 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.
Yep, all those options become viable once you break the single server
dependency.
Thanks for your input.
Cheers
Pete
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
