James Ward wrote:In my opinion 1000 is a very high number.
James Ward wrote:
200-300 should be ok
James Ward wrote:
1. Instead of having long polling, why not poll the server every few seconds. This is likely to give you better scalability.
James Ward wrote:
A typical configuration could be 3 machines. One which has Apache (load balancer), and two machines behind it, each having 2 instances of Tomcat on it. A multiple CPU machine would be good. Usually the number of threads you can handle is significantly dependent on the speed and number of CPUs you have.
James Ward wrote:
Just curious, are you using Blaze-DS/LCDS (Adobe real-time collaboration servers) by any chance. (They have a channel which is called amf/long-polling)?
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
A colleague of mine told me that all the instances and load-balancer can all be on the same machine, that's incorrect?
Do you know if it's more towards the 200 or the 300? As obviously 200 will be a bit of a problem for me
James Ward wrote:
A colleague of mine told me that all the instances and load-balancer can all be on the same machine, that's incorrect?
Yes ofcourse you can put all in one powerful machine.
Do you know if it's more towards the 200 or the 300? As obviously 200 will be a bit of a problem for me
Depends on underlying hardware too, but 300 should be ok.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:sustained 500ms or less responses for web requests is pushing it. There's too much overhead, and none of the mechanisms - including HTML itself - were designed for ultrahigh performance. This is a protocol that was intended to permit humans to obtain information over a long distance through a chain of routers, switches and hosts, and although good HTTP apps should be able to provide turnaround in no more than a few seconds, milliseconds is probably asking too much.
For something like that, I'd recommend a more interactive, lower-overhead protocol such as RMI, where you could embed a client connection in an applet. Although realistically, I'm not sure that you can expect the humans looking at the displays to be capable of taking advantage of sub-second updating over extended periods of time.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |