HACKERS
Damned hackers!
If you've been trying to access my blog for the last couple weeks, I do apologize. Some POS hacker managed to find an exploit into my Wordpress blog and inserted links to some Russian malware sites. Rather than allow the exploits to be served up, I took my entire blog down.
I have now replaced my Wordpress blog with a Python CGI-based blog. I've moved the content over, but I still have to do some cleanup. So please bear with me - the blog will soon be back to it's former state, minus hacks.
No comments
Categories: hackers, blog
Date: 2012-11-10 14:40:49, 3 years and 260 days ago
See you in Chicago on Saturday, Sept 22!
Dan Mahoney will be one of the presenters at the BARcampChicago event at 1 p.m. Saturday, Sept. 22. His topic is How to Stream Live Video.
The talk, one of several scheduled for the day, will introduce participants to the tools needed to stream video, the various sources of software and services, and some of the pitfalls to avoid.
Check out the BARcampChicago site for info about the event, how to register, and how to suggest topics for the group.
Pumping Station One (3519 N. Elston Ave) will be hosting BARcampChicago. The doors will open at 9:30am on Saturday Sept 22 with an introduction starting at 10am and talks following. The space will be open until 7 p.m., says the BARcamp website.
See you in Chicago, Sept. 22!
Nancy
PS: Dan is systems engineer at Clickstreamtv.net, which provides an online video platform. i See his resume, etc, at http://www.furtechgroup.com/about-us/dan-mahoney-geek-and-cat-lover.html
No comments
Categories: streaming, python, Chicago
Date: 2012-09-21 13:47:32, 3 years and 310 days ago
Load testing streaming servers
One of the challenges we face trying to get a commercial–quality streaming server set up is how to test the server's capacity to respond to heavy stream loads. As handy as manufacturer spec sheets can be, it's one thing to read that your EC2–based server should be able to handle 150 Mbps of outbound stream and another to be willing to commit to that capacity in your business planning.
Let's say the live events you encode are being sent at a bit rate of 500 Kbps. Let's also say that you are running a streaming server on a single EC2 small instance. A single EC2 small instance should be able to deliver 150 Mbps, or about 300 streams at once. How do you verify this? It's usually not easy to call up 300 friends and have them all hit your server at the same time, and no matter how many computers you have at home or at the office it's unlikely you can get your hands on enough of them to make 300 requests at once.
This is where a load testing tool comes in handy.
The load testing tool I'll describe here is called Flazr, and itâs open source (GPL3). You can find it at http://flazr.com. There is also a wiki at with the specific content we want at http://sourceforge.net/apps/mediawiki/flazr/index.php?title=Main_Page.
If my Wowza (or FMS, or crtmpserver, or Red5) server is at mystreamserver.com, my live streaming application is named "live", and I'm pushing a stream with a name of âteststreamâ, I can impose a load of 100 connections on my server by running:
./client.sh –app live –host mystreamingserver.com –load 100 –port 1935 teststream
For example, if I encode the stream described above and send it to live.clickstreamtv.net/liverecord and use my stream name and auth key (stream name of 1084563), and use a command line of:
./client.sh –app liverecord –host live.cckstreamtv.net –load 10 –port 1935 1084563
then look at the "connectioncounts" page on the server (not accessible to our streaming customers but available internally) I see:
1084563
10
0
0
0
0
10
What are the limitations? If youâre doing this from your laptop while sitting at Starbucks, connected over their free WiFi, and trying to pull 50 connections you will be disappointed. In order to get meaningful results you will need to have:
a machine (or machines) with enough horsepower to run the JVM (Flazr is written in Java) and run potentially multiple threads
a connection with enough bandwidth to pull down the appropriate number of streams
The stream I usually use for testing is 500 Kbps of video and 96 Kbps of audio, for a combined total bit rate of 596 Kbps. If I am pulling down 10 connections to my live stream, I will be sucking down about 6 Mbps of content. If I increase the "–load" value to 100, my downstream bit rate increases to 60 Mbps.
One way to get access to affordable compute horsepower and bandwidth is to use an Amazon EC2 instance. A large instance goes for $.32/hour and offers 250 Mbps of bandwidth, so if all you need is to do a couple hours of testing you can move quite a bit of data on a large instance. The charges stop accruing when you stop or terminate the instance.
IMPORTANT NOTE regarding load balanced systems: If you are running Wowza in a load balanced origin/edge configuration you must remember that this test method will NOT exercises the load balancer! It just pulls a stream from the machine name in the command line and does not follow HTTP redirects.
No comments
Categories: streaming, testing, Wowza, flazr
Date: 2012-08-24 15:16:10, 3 years and 338 days ago
I upvoted You