Alex, are trying to save bandwidth? oops, I've missed that part, I though he was afraid the server would enter DoS or something. I agree that using a balancer will do absolutelly nothing about bandwidth costs or usage, and yes, you're right about pound getting all the requests before distributing them.
So what about transfering some balance logic into the client application. It could first download a simple text file with a list of available servers and with each request go round-robin them. This will not save bandwidth (I don't know how to do that) but would help distributing things among a pool if the traffic gets high. The file could have the ip of the server and some priority or something like that, so in case of timeouts and some little math, things could be worked out. As for saving bandwidth, why not use GZip encoding for the transfers, it saves some bytes. Andre On Mon, Feb 16, 2009 at 7:22 PM, Alex Tweedly <a...@tweedly.net> wrote: > Andre Garzia wrote: >> >> Sims, >> >> I think the trick is not on the client side but on the server side. >> Instead of pointing your Rev client to a fixed server, use a balancing >> solution, there are load balancers that are able to distribute the >> request among multiple servers so that you can scale (add more >> servers) as needed without the need to rewrite things. >> >> This way you script your app normally, but on the server you put >> enough logic so that you can add more servers to a pool if you see >> that it is getting hard to cope with the demand. >> >> One good balancer is 'Pound': http://www.apsis.ch/pound/ >> >> With a solution like that you'll be able to plan your scaling needs. >> > > Sorry, andre, but I have to disagree. Most load-balancers, including Pound, > allow you to scale your servers - but they do nothing to save on bandwidth. > Each request comes to the same loadbalancer, which distributes them between > back-end serves. So one of the the original concerns, web traffic, is > undiminished - the same level of traffic passes over the network-facing > interface in either case. > > In general, load-balancing is most effective when the processing required is > considerable, and that can be shared beteen servers; or when the quantity of > data output is significant (and you use the request redirector feature). But > in this case, the typical request is small, and results in a small amount of > output data (i.e. a one line file). > > So although I'm all in favour of these schemes (I helped develop what I > think was the first commercially successful load distributor, Cisco's > Distributed Director :-), I don't think it does much in this case. > > Also, in this case, we hve control over the requesting app, and so have > capabilities not available to the average Web developer. (see also further > reply to sims email ...) > > -- Alex. > > _______________________________________________ > use-revolution mailing list > use-revolution@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-revolution > -- http://www.andregarzia.com All We Do Is Code. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
