The other thing to think about is whether you need to use an SQL backend
at all for this kind of shared data.
May web solutions are written using SQL backends and this kind of session
persistence because the web site coders / designers don't know any
better.
Adrian
On Sat, Dec 19, 2009, Peter Rundle wrote:
> >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
--
- Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support -
- $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
