There's also clustering in MySQL 5 that looks very enticing to me as an
additional layer or scale out and redundancy. It's not your typical
master/slave scenario and actaully allows for real load balancing and
failover.

> -----Original Message-----
> From: Jeremy Brooks [mailto:jbrooks4@austin.rr.com]
> Sent: Tuesday, May 09, 2006 11:19 AM
> To: 'Jeremy Brooks'; 'Perrin Harkins'; 'Ken Perl'
> Cc: modperl@perl.apache.org
> Subject: RE: clusters
>
> As a caveat to the E-mails about caching pages using a proxy,
> the usefulness of such depends on how much traffic your site
> will see to static pages. In our situation, the only static
> pages are our "contact us" page, "privacy policy" ,etc.
> Those pages don't get enough traffic to justify the
> maintenance of setup overhead of a proxy. Our main page is
> not static and neither are the product and category pages.
> Actually over 99% of our pages are dynamic with rotating
> specials and such. The usefulness of caching on pages via a
> proxy also depends on your typical landing pages.
> If you have a customer click to your site to a page with
> dynamic content (specials, session IDs in form data, etc)
> then caching to the most frequently viewed pages is useless
> and even damaging/problematic.
>
> Regarding Round Robin DNS, this scenario will become a
> nightmare should you loose a server that is not redundant on
> the same IP. Even with a very short TTL, your customers will
> see more downtime then they like and may go elsewhere should
> you loose a server. DNS load balancing is generally not a
> wise load balancing method because it's NOT actually
> balancing load in real time.
> The affect of round robin DNS is something akin to breaking
> up load sometime last week and hoping it all works out today.
> It's not really an active solution since servers die and
> nothing changes in the customers view for quite sometime. In
> fact, TTL must be reached before other DNS servers update
> their cache and most importantly, your customers PC must
> actually begin to us the new IP to connect! So, now you're
> dependent on DNS client
> caching on your customers PCs... Not good. On a Windows PC
> this can mean
> restarting the browser, on an OSX machine this may mean
> restarting the damn machine (really, I've experienced this).
>
> Go with IPVS as a base and proxy if it makes sense. Use DNS
> load balancing only if you have redundancy on each node
> connected to each IP and if load balancing public IPs is to
> much pain otherwise.
>
> You can use IPVS in several different topologies or you can
> mix them to get what you want.
>
> http://www.ultramonkey.org/3/topologies/
>
>
> -Jeremy Brooks
>
>
> > -----Original Message-----
> > From: Jeremy Brooks [mailto:jbrooks4@austin.rr.com]
> > Sent: Tuesday, May 09, 2006 10:26 AM
> > To: 'Perrin Harkins'; 'Ken Perl'
> > Cc: modperl@perl.apache.org
> > Subject: RE: clusters
> >
> > We use Ultra Monkey (IPVS) to cluster our E-com site with commodity
> > hardware.
> > Your application needs to cache sessions in a common

> database table in
> > order to make session work consistantly.
> >
> >
> >
> > > -----Original Message-----
> > > From: Perrin Harkins [mailtoerrin@elem.com]
> > > Sent: Tuesday, May 09, 2006 7:28 AM
> > > To: Ken Perl
> > > Cc: modperl@perl.apache.org
> > > Subject: Re: clusters
> > >
> > > Ken Perl wrote:
> > > > Is it possible to make a modperl application to run in cluster?
> > >
> > > Of course.
> > >
> > > > if yes, how to do that?
> > >
> > > The same as any other web system -- multiple machines, a load
> > > balancer, shared data on a database or other system.
> > >
> > > > any doc?
> > >
> > > Tons of them. Practically any doc about clustering will

> apply. I
> > > wrote one ages ago about one mod_perl site I worked at:
> > > http://perl.apache.org/docs/tutorial...oys/etoys.html
> > >
> > > Is there some specific part you're having trouble getting

> your head
> > > around?
> > >
> > > - Perrin

>