[Red5] stress test results

[Interalab]

The script returns that there is no applicable hardware to fix.  I'll 
keep looking.

Luke Hubbard wrote:
> Hi Bill,
>
> Thanks for running this test. The cpu numbers are promising if we can
> fix this other issue. Can you provide deals of how much memory the
> red5 process was using.
>
> To be clear every time the server died it didn't hang its process
> died. That is very odd, if there was some exception it should have
> been logged. I suspect something happened in a native networking code
> which killed the java process. I googled those errors you got in your
> system logs and found this..
>
> http://osdir.com/ml/linux.drivers.e1000.devel/2007-01/msg00133.html
> http://www.kaltenbrunner.cc/blog/index.php?/archives/8-fixing-e1000-TX-transmit-timeouts-at-least-some-of-them.html
>
> Sounds like it might be possible to fix the error by adjusting the nic settings.
>
> Is anyone else getting experiencing the same symptoms?
> Process dieing without hanging or throwing any errors? If so please speak up.
>
> Luke
>
> On 5/8/07, Interalab <sales at interalab.com> wrote:
>   
>> Rob Schoenaker and I ran a little stress test this morning and wanted to
>> share our results.  Rob, feel free to add to or correct me if you want.
>>
>> This was a test of one publishing live stream client and many
>> subscribing clients.
>>
>> Here's the server config:
>>
>> Xubuntu Linux
>> AMD 64 3500+ processor
>> 4 GB RAM
>> Red 5 trunk ver 1961
>> Gbit Internet connection
>>
>> Client side:
>>
>>  From the other side of the world . . .
>> Lots of available bandwidth
>>
>> The first run choked the server at 256 simultaneous connections.  They
>> were 250k - 450k live streams.
>>
>> After a re-boot, we got up into the 300 + connections.  This time the
>> resolution was lower, so the average bandwidth per stream was about 150k
>>
>> Server looked like this:
>> Cpu(s): 12.0%us,  2.0%sy,  0.0%ni, 84.0%id,  0.0%wa,  0.3%hi,  1.7%si,
>> 0.0%st
>>  Mem:   3976784k total,  1085004k used,  2891780k free,     7896k buffers
>>  Swap:  2819368k total,        0k used,  2819368k free,   193740k cached
>>
>> After about 15 minutes, and over 400 connections, Red5 quit without any
>> log errors.  The Java PID just went away.  Had a bunch of these in
>> dmesg:  e1000: eth1: e1000_clean_tx_irq: Detected Tx Unit Hang
>>
>> Started Red5 by running red5.sh without re-booting the server.  It came
>> right back up and started streaming again.
>>
>> This time, we set the resolution to 80x60, or about 60-80 kbps per stream.
>>
>> Rob tried to crash it by launching about 200 connections in about 10
>> seconds, but it kept running.  It didn't die again.
>>
>> Final outcome of the last test:
>>
>> 627 concurrent connections peak
>> approx 1100 connections total (some dropped when browsers crashed under
>> the load, etc.)
>>
>> At the peak, player buffers started to get big.  Some as high as 70,
>> most of mine were in the 30's.
>>
>> So, my observation is that even though the server and available
>> bandwidth didn't seem to be stressed too much - lots of memory and cpu %
>> in the teens, the larger the individual streams, the fewer total
>> connections we could make.
>>
>> Not very scientific, but we thought it was worth sharing with the list.
>>
>> Regards,
>> Bill
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Red5 mailing list
>> Red5 at osflash.org
>> http://osflash.org/mailman/listinfo/red5_osflash.org
>>
>>     
>
>
>