My apologies, but for some reason salman's reply didn't make it to my
news server. So I'm going to reply to the reply to his post. :)
Scott Gifford wrote:
salman <al*******@gmail.comwrites:
>Thanks Peter
I am working on a trading application, and there is 1 MB link on
trading server. Normally at a time 25 to 30 TCP clients are connecting
to server. If more than 30 clients (TCP connection) connect to the
server, then perform is going down.
In addition to what Scott already said, I'll ask this: for whom is
performance going down?
If you have some other critical application on the network that is being
affected, then I can see why you'd want to limit the bandwidth of the
(apparently?) non-critical application. As Scott says, given what
you've written so far it sounds like just extending the timer for the
requests would be beneficial.
Perhaps introduce some sort of randomization to the timer so that you
minimize the effects of clients all hitting the network at the same
time, or do as Scott suggests and use some sort of queuing mechanism
that ensures the clients never make the request all at once.
Beyond that, a couple of non-software suggestions:
* If you have a critical application that you want to avoid
interfering with, perhaps the best solution is to ensure that
application is on its own network, separate from the other stuff.
* If you don't have a critical application and it's just
performance of these clients that suffers, then perhaps letting that
happen is truly the simplest solution. After all, limiting bandwidth
artificially is going to cause performance to suffer anyway, but it will
be all the time instead of just when you have a lot of clients present.
It's true that network congestion can make things worse than just
limiting bandwidth, but IMHO you'd have to be getting a lot more clients
than just over the limiting number before that starts to be a really bad
problem.
If you do need to limit bandwidth, I'd go with Scott's suggestion for
something like this. The more general technique of actually monitoring
throughput and using timing to control the throttling of your network
i/o is probably more suited to streaming applications, like file
transfers, media applications, etc. If you have a well-defined
protocol, you can essentially pre-process all the timing work and just
control a specific interval controlling how often the protocol uses the
network.
Pete
