tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: How tomcat is handling bandwidth sharing across all request
Date Wed, 11 Sep 2013 18:13:06 GMT
Hash: SHA256


On 9/11/13 1:48 PM, David kerber wrote:
> On 9/11/2013 1:38 PM, Arun Kumar wrote:
>> Hi
>> We are developing small video hosting application ,we are not
>> writing any special program for open the video file and send to
>> player , simply we are using tomcat DefaultServlet for above all
>> video request , now we have to benchmark our application for
>> following scenario
>> 1) video size 100MB (1080i HD) 2) Total Network bandwidth 10Mbps
>> (IN/OUT)
>> Now how to calculate how many max thread is allowed for above
>> scenario ,with out interrupting users viewing experience,  here
>> each video response should secure 400kbps bandwidth for no
>> interruption
>> So my question is how many concurrent users can view videos
>> without interrupt then how to test this scenario ,and how tomcat
>> is handling bandwidth sharing across the request
> Tomcat doesn't do any bandwidth sharing internally; that's up to
> your OS and network infrastructure.  Basically divide your network
> bandwidth's slowest point (probably the ISP connection) by the 400k
> you say you need per connection.  That is the number of
> simultaneous connections you should be able to support, assuming
> your server hardware can handle it (which it probably can).

There are lots of other factors to consider as well. A naive client
might download the entire movie before playing it. Disconnects might
end up higher than zero, so the client will have to tr-try and -- it
being a naive client -- might just re-start from the beginning. A
smarter client might be able to do a HEAD request to get the file size
and then use separate requests for chunks of a single file. If the
client thinks its being smart (but is really dumb), it might request
those chunks simultaneously "to improve performance".

If your 400kbps requirement per connection is well-researched and
correct, then you can handle:

 (X bandwidth in kbps) / (0.7 * 400 kbps)

The 0.7 factor is a rough estimate of network "waste" chatter required
to actually communicate. For example, if you have a 100Mbps
connection, you can't actually communicate data at that speed: the
connection supports bits moving at that speed, but there is more data
flying around than the data your application cares about.

- -chris
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message