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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > 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 [mailto:[EMAIL PROTECTED] > > > 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/tutorials/apps/scale_etoys/etoys.html > > > > > > Is there some specific part you're having trouble getting > your head > > > around? > > > > > > - Perrin >
