On 31 Jan 2009, at 20:37, John L. Singleton wrote:
> Performance isn't the only reason to consider clustering. The other > reason is availability. If you have an application that must > absolutely be available 24/7 then you must cluster. IMHO there isn't > really a way around this if availability is a requirement. The > thinking is that it's highly possible that *one* machine can > experience some fatal hardware failure but much less likely that *all* > of your machines will... at least at the same time. Whilst I agree with that, clustering for availability has to be done in a certain way. No point adding extra webservers if you still have a single database server. The object of the exercise is to remove ALL single points of failure - which also means redundant internet connections (to different carriers), multiple power supplies (on different power circuits), failover switches, multiple LAN cards etc. *ANY* SPOF is the weak link in the chain, and *ALL* are as valid as each other, so they all need to be eliminated. Availability is the most expensive reason to cluster, and again - this is an entire subject in itself. > *If you want to go with a software load balancer, try HAProxy: > http://haproxy.1wt.eu/ > --- Few hosts offer load balancing, so if you host anywhere you'll > have to build your own cluster. If you're clustering for availability ALWAYS build your own cluster. That way you know for sure it meets your spec, and you know it's going to do what you want it to. There are 2 useful books on this kind of topic : Enterprise Data Center Design and Methodology (Sun) Build the Best Data Center Facility for Your Business (Cisco) Last year (or it may be the year before now...) there were several cases of hosting centres loosing power, and the backup generators failing because they were never tested. Test the scenarios - don't assume your plans will work. > > > On Jan 31, 2009, at 7:43 AM, Jacob Coby wrote: > >> >> >> On Jan 31, 2009, at 5:28 AM, Sumedh wrote: >> >>> >>> Very good discussion... :) >>> >>> Idea of creating a Ramdisk and putting cache folder on that is >>> neat... :) >> >> Yes, neat. And totally worthless on a Linux server. Linux already >> uses excess ram to cache commonly accessed files. You're just taking >> ram away from processes that could actually use it. A good portion >> of >> it will be kept empty since you have to allocate more space than you >> actually use. I imagine the same applies to *BSD and probably >> Windows >> as well. >> >> Ramdisks were a great idea around MS DOS 5 when you wanted to get rid >> of diskette seek times. They're worthless now. Use a php opcode >> cache instead. You'll get a 10000x better ROI on that 64mb than >> adding a ramdisk. >> >>> >>> >>> Can someone point me to a resource that tells me typically what is >>> the >>> amount of traffic when one needs to think of clustering very >>> seriously... >> >> You look at clustering when you can't operate on just one server >> anymore. There is no typical amount of traffic. It's wholly >> dependent on your site's performance and your (or your company's) >> willingness to spend money. >> >> In short, you will know when you need to start looking at it because >> it will be your only option. You've added an opcode cache. You've >> added a dedicated database box. And then upgraded it. You've >> upgraded your webserver. You've added memcache. You've enabled sf >> caching. You've optimized slow queries. You've triple-checked the >> database settings. You've gone over the code a dozen times to make >> sure you're not using a boneheaded algorithm somewhere important. >> You >> still can't keep up with traffic. It's time to start looking at >> scaling out. >> >> It's been my experience that you should avoid it as long as possible. >> Adding multiple servers that perform the same task will lead to >> headaches and rising expenses and will slow down development. >> >>> >>> >>> And which are good hosting providers offering load balancing etc? >>> >>> On Jan 28, 6:12 am, Pablo Godel <pgo...@gmail.com> wrote: >>>> I was not using symfont at the site. I was trying to cache queries >>>> results and rendered templates. >>>> >>>> Pablo >>>> >>>> On Tue, Jan 27, 2009 at 7:46 PM, Lee Bolding <l...@leesbian.net> >>>> wrote: >>>> >>>>> Memcache can cache anything - be that a DB query, an object, >>>>> etc... >>>> >>>>> http://code.google.com/p/memcached/wiki/FAQ#Cache_things_other_than_S >>>>> ... >>>>> ! >>>> >>>>> On 28 Jan 2009, at 00:34, Eno wrote: >>>> >>>>>> On Tue, 27 Jan 2009, Pablo Godel wrote: >>>> >>>>>>> I rememeber trying this and I did not see a noticeable >>>>>>> improvement, I >>>>>>> am not sure if I did something wrong. Instead, we used memcached >>>>>>> and >>>>>>> we did see a big difference. >>>> >>>>>> memcached caches your database queries, but maybe your actions >>>>>> were >>>>>> not >>>>>> fully cached? On a site with a lot of pages you will have a huge >>>>>> cache (in >>>>>> our case, a couple Gb of files!). >>>> >>>>>> -- >>>> >> >> -- >> Jacob Coby >> >> >> >> >> >> >> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
