Hi,
StreamingLoadTool does not have to be on the same machine as QTSS. Its
actually better to run it on remote machines so that it doesn't use up the
server's resources. You'll need to modify the "streamingloadtool.conf" file
to customize it for your purposes. The file is in
/Library/QuickTimeStreaming/Config or /etc/streaming depending on your OS.
Then run "StreamingLoadTool -f <config file>" specifying where the config
file is.
The remote server will need to have a hinted movie in its Movies directory
called "streamingloadtool.mov", which tells StreamingLoadTool that its okay
to send requests to the server.. You can just copy one of the sample files
to "streamingloadtool.mov" to create the file.
StreamingLoadTool performance is limited by a few factors- per-process UDP
limits, OS networking limits, etc. For 2-track movies, you probably won't
be able to get more than 200 clients per StreamingLoadTool session- see the
"concurrentclients" option in the config file.
You'll probably want to set the "runforever" option to "yes". This will
request all of the streams simultaneously, and will loop when the time
specified by "movielength" runs out.
To best simulate most real-world conditions, you'll want to use the
"reliableudp" transport. You can also increase the "overbufferwindowsize"
to better simulate actual clients.. something higher than 16384 would
probably be best.
You can have StreamingLoadTool create a log file for analysis. If you do
this, you'll want to ignore the reported packet loss in the log, since it
isn't calculated correctly. The best way to determine the server's limit is
to use the following method:
1. Connect X amount of StreamingLoadTool clients to a movie.. Ideally the
movie should be > 1 or 2 minutes long, because the clients will cause more
stress on the server if they disconnect/reconnect to the movies.
2. Connect a QT player to a movie and view the stream, looking for packet
loss in the stream. You can use command-J to view the stream info and watch
for packet loss.
3. If the stream still looks good, then return to 1. above and connect more
clients.
You can run "top" on the server during the test to watch system resources
and determine where any bottlenecks are.
StreamingLoadTool may work better on some platforms than others.. The unix
platforms tend to be better than Windows from what I've seen.
Please let us know if you have more questions.
-Joel Hedden
On 10/10/02 6:43 AM, "Marisa Affonso Vasconcelos" <email@hidden> wrote:
> Hi,
>
> Which bitrate do you use to get 4000 concurrent live streams?
> How can I use the StreamingLoadTool and streamingserver.xml? The load tool
> has to be in the same machine of the streaming server?
>
> Thanks in advance
> Marisa Vasconcelos
>
>
> On Wed, 9 Oct 2002, Joel Hedden wrote:
>
>> Hi,
>> We don't publish official performance results, but we have seen over 4000
>> concurrent live streams (low-bitrate) served using an XServe QTSS server.
>> Your performance is largely dependent on the bitrate and size of the movies
>> used, and the transport that the clients are using. Also, reflected streams
>> use less CPU and RAM than on-demand streams.
>>
>> If you're planning on deploying DSS and are interested in what kind of
>> performance you can expect, I would recommend running some scalability tests
>> for yourself. We include "StreamingLoadTool" which can be used to simulate
>> large numbers of client connections.. but you will have to run several
>> concurrent instances of the program, probably on multiple client machines.
>> With DSS, you'll probably need to optimize the OS some in order to achieve
>> the best performance results. You can also tweak the DSS
>> streamingserver.xml file to improve performance.
>>
>> Please let us know if you need help using StreamingLoadTool or other
>> questions regarding performance/scalability.
>>
>> -Joel Hedden
>>
>> On 10/9/02 12:26 PM, "Marisa Affonso Vasconcelos" <email@hidden> wrote:
>>
>>> Hi,
>>>
>>> Are there studies about Darwin Performance? For example, number of
>>> clientes served, CPU and memory utilization?
>>>
>>>
>>> Thanks in advance
>>> Marisa
>>> _______________________________________________
>>> streaming-server-developers mailing list |
>>> email@hidden
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/streaming-server-developers
>>> Do not post admin requests to the list. They will be ignored.
> _______________________________________________
> streaming-server-developers mailing list |
> email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/streaming-server-developers
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
streaming-server-developers mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/streaming-server-developers
Do not post admin requests to the list. They will be ignored.
