Just a quick heads up to those that haven't upgraded to FMS3 and don't plan to for a bit that FMS2.0.5 has been released. Fixes some bugs, especially a big one where an exploit was in place that a DOS attack on the server could drop it.. to quote it:
A DOS attack caused by sending bad data to the server which resulted in huge memory allocations has been prevented.
The link is good for linux at the moment but the windows DL link is dead. Go figure.. Adobe, they specialize in the software but don't make sure that a link is not going to a 404 :O I'll update again when I know the link is live.
Update (6PM PST): Windows file seems to be online now.
Just reading an article on yahoo about RealPlayer once again pissing off the public with invasive software and not notifying users as to what exactly their software is doing. Here is a good quote that sums them up:
A widely used alternative to Apple's QuickTime and Microsoft's Windows Media Player, RealPlayer has a history of making invasive changes to users' computers. The Message Center software has come under fire in the past, and in 1999 computer security consultant Richard Smith discovered that the software was quietly sending information to RealNetworks servers.
This along with that it gets in the way of FLV playback due to snagging the stream before it reaches the SWF file (or something like that)... honestly, it would be nice if the RealPlayer just fell into the abyss and was never seen again.
Ever since I got up the new FMS community site fmsguru.com it's been kinda rare to get in anymore "Ask an FMSGuru" questions. I think people are just asking on the forum now or are finding their answers in the ever increasing amount of information that is on the internet about Flash Media Server. That's good I think. This particular question came in a while back and I quite literally just completely forgot about it. Sorry about that Mr. Question Sender.
The question: How do I load test my Flash Media Server applications?
The answer:
Boy this is a bit of a tough question. My first answer to this is to find a whole bunch of users to try it out. But that isn't always possible. If you happen to have a huge site with lots of users that are willing to play with the app for you to see how it runs, then great. Go for it, some people will do some testing for a free week of some service on your site or something, some will just do it because they care about the site itself. But, for the most part this isn't quite a possibility. So what else can we do?
First thing to think about is what kind of app it is. I'd say for the most part people are wondering how a data centric app is going to run. Like chats or conference applications maybe. Games are a big one too and sometimes just to see how well the server can handle lots of streams others may have a request to load test a live streaming app or prerecorded video streaming app. If you are testing a game or chat or conference app then it's important to write a bit of an AI for your app. In other words, it has to act without you doing anything so that you can watch it go.
As a basic example for a chat app you would write a quick script that randomly tosses in sentences of varying lengths to the chat at various times. This would sort of simulate a bunch of users chatting rampantly. More computers the better. Then perhaps this chat has a video feature in it where up to 5 users or something can send video. So you have to setup computers that have cameras connected to them and again have each app randomly start sending it's video. Maybe when somebody's video is detected then others will automatically play it etc. All of these things are important to see how your application is going to react to different types of loads and reacts to your code both on server and client side. Doing a very controlled test is COMPLETELY different from doing a random test like that where you don't essentially press "play" on the sending side, and after visually confirming that the video is sending and a little camera icon shows up in the userlist to then pressing "play" on the receiving side to watch that video and a little eye icon shows up on the userlist to indicate to the other user that you are watching them. This kind of stuff just plain breaks if your code has holes in it or isn't timed well.
Now, I wouldn't call it easy to go about creating that type of code and I wouldn't really know where to begin to put up some generic code to get somebody started with it because every app is different in how it's going to work and what will need to be tested and how the AI should be implemented. But the idea is there and should give you a bit of a start on where to go with the testing process.
There are a few options here for getting the numbers in. Find access to a bunch of computers and get a couple more friends etc to run a few instances of the app at the same time to see how it goes. Next best is to have a few computers running many instances of the app on one HTML page. Essentially you embed something like 10 instances in one HTML page, passing in flashvars that are all different (user IDs, usernames etc) and then they all start acting on their own with your AI code. That kind of testing will generally work with a few good computers that can handle the load of a bunch of instances running at once. Saves you from opening 10 instances of swfs too. If you don't have nonscaling on then you can squish the app size down a bit. Then you watch the server load and maybe have one dedicated PC that is running one instance of the app to see how it handles the load of 100 users or so.
Of course, the very best is to get real humans to jump in on the app. There's nothing like having people come in and double click stuff and do things out of order (at least in your head) or slightly later or earlier than you expect them too. That's when the holes in your app can show up and perhaps begin to place odd loads on your script and the server.