How I did a streaming Test

Hi,

I nearly promised to write about "the syn that's not replied" and "The port can not be opened" but I have something better to write about now. Well I've already written most of it already ;)

This is about a streaming test I've had performed for the GSM operator I'm consulting in Thailand. Have you ever encountered a streaming server to be load tested? Well I've in the last few weeks. It was a success let alone the bandwidth bottlenecks of my vps provider [1] Vpshispeed of Thailand.  I'm possibly going to retry these test with more Thailand bandwidth to reach my tests target in a later time. Any help on huge bandwidth vps or cloud providers in Thailand?

I'm bound to thank Diederik dee Gee for all the help he has provided to me. Thank you Diederik. It's been a really pleasure to work and talk with you! Also I must tell that that bottleneck was not any fault of Diederik's side. It's just I had consumed all the bandwidth available to his service and even I could use more than he has promised. His service exceeds his promises ;) I strongly recommend his services for anyone in need of vps in Thailand.

If I return to the foundation of my load test, as you already know it's a hard process. Also seemingly there are virtually no tools to load test a streaming server. So I had to improvise about it.

My concerns for a streaming load test are as follows:

• No tools -
  Build in house scripts or tools.
• Bandwidth -
  Streaming is bandwidth intensive so you need huge amounts of it.
• What to monitor and how to analyse data? -
  For a web server load test we have many tools and patterns to use. Like ab, jmeter and many many more and easy structure to make the test. "Fire requests and receive responses." But how to load test a streaming server? It's not http.

So I prepared a foundation to design my tests. My Foundation is as follows:

1. Receive Assumption: Users has enough bandwidth to saturate itself for maximum performance and keep busy the server at most.
2. Receive Assumption: Users can consume all the data it receives or has enough buffer for constant data receiving.
3. Receive Assumption: Users has enough time and patience to consume streams from beginning to end without any exceptions.
4. Consume Assumption: users has a limited buffer but overflowing data is received with the next burst added to the received data.
5. Consume Assumption: users consume data in a constant bitrate relative to the bitrate of the stream
6. Server Assumption: Servers are more bandwidth constraint then memory or cpu.
7. Server Assumption: Different protocols for streaming only has minimal effect on cpu and memory usage on the server side

After creating my foundation I started searching for tools to use. Because of assumptions 6 and 7 I decided on focusing on a single protocol and with the openrtsp tool [2] and (live555 Streaming Media Library [3]) availability rtsp seemed to be a suitable choice.

But as is, OpenRtsp would not give me any data to analyse. So I quickly hacked one of its samples into giving me data about stream bursts and put the received data into void. As this would only give me raw data about the network usage I built a simple python tool to analyse the raw data in a simplistic but informative way. This tool gives a [4] gnuplot data file about the data burst which then be used to create graphs of the bursts in a visual way.

I've put the foundation into github and can be pulled from [5] https://github.com/fsniper/streaming-loadtest-foundation . There are more info in the README file in the repository.

All pull requests are welcome ;) Please don't be harsh and please try to be constructive with your comments. These are hacks as they are right now.

[1] http://www.vpshispeed.com/en/
[2] http://www.live555.com/openRTSP/
[3] http://www.live555.com/liveMedia/
[4] http://www.gnuplot.info
[5] https://github.com/fsniper/streaming-loadtest-foundation

Hello for my torments! And what's happened?

Too long it has been, since I've written on the internet.  Too much has came and gone. I've done many things, passed many. I even don't know why I started writing back. Especially why in English? I believe, I do not have a clear answer to that question.

Maybe I need to practice writing in English? Maybe need more audience?  It does not matter. I will be writing in English and will have too many mistakes but won't care. I'll just write if I can. I do not promise anything. Promises are a burden if they can't be kept. I even has one on my shoulders that I could not manage to fulfil. Once I promised some of my college mates to cook for them. I still feel the urge. So long, and I even lost contact with many of them. Never mind, that's a lost cause. .

Since the last post I tried to write once and could not finish. I'm more inclined to finish this time. I know, if I pause, or postpone that means another half an effort that's lost.

I'm in a hotel bed in a foreign country now. I'm in Bangkok and started the feel the urge to write again. I've been abroad since my last post. Been to North Cyprus, Bahrain, Greek Islands and now Thailand. Some of them for work, some of them for leisure. But always with a leisure sauce.  In Bahrain I worked for Batelco, Ericsson, Parkyeri as an outside consultant. In Thailand I'm consulting at Parkyeri for TrueLife this time. Greek Islands and Cyprus was all leisure. 

In Bahrain I travelled the country with a rental car and stuck in desert to be rescued by U.S. Soldiers. (thank you uncle Sam!) In North Cyprus gambled and won to loose on adultery ;)  In Greek islands I was on a cruise ship and with my ex. And I'm in Thailand now. Not yet have much leisure. But I'm sure to have some in the coming days.

What will I be ramble about? As the name suggests, I'm a Linux System administrator and will be rambling about my experiences or my torments of all about system administration and anything that's complementary for it. Like the torture of my beloved two friends Barış and Barış's cycling tour designed to torture me!. For the tour route look at  http://dunyadangecerken.com/?p=38756

Now I have to sleep some. So see you! Maybe I will write next about my last struggle with  "unreplied syn" and my friends "port that can not be listened".