Hello Larry,
>Billy,
> You stated that Don should try to test the SpamPro tool versus the
>2.0.1 version of the server. If he does this, how do you expect him to
>verify the number of connections the server "thinks" are active without the
>web admin tool available in 3.0Preview? Is there another method in 2.0.1 to
>get this information? If not, he has no way of verifying the connection
>counts of SpamPro versus the 2.0.1 server.
>
>Larry
You asked a great question, and here is the answer:
To be able to monitor a Darwin/QTSS 2.0.1 server's
thruput and client connection, you will need to
enable 'web_stats_url' (in /etc/streamingserver.conf):
0. First kill off any QTSS streaming processes
1. Edit /etc/streamingserver.conf
2. Change the line that contains "web_stats_url" to read
something like this (note, stats can be any private
word that you like, it doesn't have to be "stats"):
web_stats_url stats
3. Now, restart your QTSS server processes
root# /usr/sbin/QuickTimeStreamingServer
4. Then use a nearby HTML Web Browser to monitor your streaming
server's current thruput and client connection count like this:
http://qtss.domain.com:554/stats
5. To view formatting tips, or to see how to make the
stats page continually refresh itself automatically,
do this:
http://qtss.domain.com:554/stats?help
This works both on MacOS X Server QTSS as well as all
Darwin Streaming Servers version QTSS 2.0.1 (and earlier).
If you want to do this with Streaming Server 3.0 Public
Preview (without using the Perl Web Admin server on
port 1220), then you do this:
0. First kill off any QTSS streaming processes
1. Edit /etc/streaming/streamingserver.xml
2. Change the line that contains "web_stats_url" like this:
<PREF NAME="web_stats_url"></PREF>
3. Make the line in streamingserver.xml read:
<PREF NAME="web_stats_url">stats</PREF>
4. Now, restart your QTSS server processes
root# /usr/sbin/QuickTimeStreamingServer
5. Then use a nearby HTML Web Browser to monitor your streaming
server's current thruput and client connection count like this:
http://qtss.domain.com:554/stats
Lastly, another trick that works well only with
QTSS 3 Public Preview (on Darwin or MacOS X) is to
run the Streaming Server attached to the command-line
printing out its status (like this):
root# /usr/sbin/QuickTimeStreamingServer -d -s 5
This will keep the QTSS process attached to that terminal
shell, while also displaying a status line every 5 seconds:
QTSS/3.0Preview [v240]-MacOSX Built on: Oct 7 2000, 15:30:16
-d: Run in the foreground
-p XXX: Specify the default RTSP listening port of the server
-c /myconfigpath.xml: Specify a config file
-o /myconfigpath.conf: Specify a DSS 1.x / 2.x config file
-x: Force create new .xml config file from 1.x / 2.x config
-s n: Display server stats in the console every "n" seconds
In fact, for performance testing of QTSS 3 Public Preview,
you may wish to use the "-s 5" method of viewing the server's
status since it is concise without the requirement of an
Web Admin browser client. Also, if you are doing large #
of client connects/disconnects, then you may want to
consider disabling access logging if you find it is causing
a performance hit.
The output looks like this (widen your email viewer if necessary)
root# ./QuickTimeStreamingServer -d -s 5
Software expires on: 2/15/2001
Number of task threads: 1
Streaming Server done starting up
RTP-Conns RTSP-Conns HTTP-Conns kBits/Sec Pkts/Sec TotConn TotBytes TotPktsLost
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
This feature is not in QTSS 2.0.1 (or earlier).
Earlier Don wrote: (Re: Questions/Problems with SpamPro)
>>If this status follows the codes from RTSP specs (RFC 2326, April '98, sec
>>7.1.1), 415 is "Unsupported Media Type". This seems bogus since hundreds
>of
>>streams with the same URL were opened and completed normally.
The 415 errors Don was getting sometimes running QTSS
3 Public Preview under stress looks like a bug. This error
typically happens when the server thinks the movie is not
hinted. We're going to try to reproduce this here at Apple.
Thanks again for your
Hope that helps.
--
Billy Brown
>Billy,
> You stated that Don should try to test the SpamPro tool versus the
>2.0.1 version of the server. If he does this, how do you expect him to
>verify the number of connections the server "thinks" are active without the
>web admin tool available in 3.0Preview? Is there another method in 2.0.1 to
>get this information? If not, he has no way of verifying the connection
>counts of SpamPro versus the 2.0.1 server.
>
>Larry
>
>-----Original Message-----
>From: email@hidden [mailto:email@hidden]
>Sent: Thursday, November 09, 2000 4:58 PM
>To: email@hidden
>Subject: Re: Questions/Problems with SpamPro
>
>
>Hello Don,
>
> Thanks for providing your feedback regarding use of
> SpamPro. At this point, SpamPro is relatively new,
> plus you were testing it against QTSS 3 Public Preview
> (which is not yet complete and is still being worked
> on and tuned here at Apple). Consider the SpamPro
> v240 as also a "Public Preview" version of the tool...
>
> > SpamPro 3.0Preview[v240] Oct 7, 2000
>
> If you have a QTSS 2.0.1 GM server to test against,
> you might want to try some of these same SpamPro client
> tests against a 2.0.1 server.
>
> This would give a little more information in determining
> if the problem really is in SpamPro, QTSS 3 Public Preview,
> or a combination of the two - by comparing how SpamPro
> works against QTSS 2.0.1.
>
> If you don't have time to re-run any of your tests
> against a QTSS 2.0.1 GM server, that's alright, but
> is something I'd consider doing. Internally at Apple
> we are continuing to work on both QTSS 3 and SpamPro,
> and are interested in all feedback and requests from
> users.
>
>--
>Thanks again,
>Billy Brown
>
>>We have been using DSS, Preview3 on Linux 2.4.0(test8) for several weeks,
>>using SpamPro 3.0Preview[v240] Oct 7, 2000. We have been testing DSS
>>behavior under high and low stream counts, and noticed inconsistencies in
>>the number of active clients (e.g. RTSP and RTP connections) reported by
>>SpamPro and the DSS administrator / WebStat URL. Specifically, if we start
>>SpamPro with 50 clients with the same URL (on a single machine), we get:
>>
>>Active Playing Attempts Success Errors Failed
>>...
>>50 50 50 0 0 0
>>...
>>
>>The clients are all running the same 60 minute 20k stream. The SpamPro log
>>file (enabled in spampro.conf) has no entries as SpamPro continues
>scrolling
>>the same numbers, leading us to believe 50 clients should be running with
>no
>>errors or problems.
>>
>>Now when we go to DSS Admin, we might see 50+ clients at first, but over
>the
>>next few minutes we see this number vascillate -- 45, 50, 35, 32, 38,
>40
>>... When we check the DSS error logs, nothing is output concerning any
>>problems, and the SpamPro output is always clean. This problem gets worse
>>when we add thousands of streams -- the difference between what SpamPro
>>reports and what DSS Admin reports differs by up to 75%. We also note that
>>if a heavily loaded SpamPro App crashes (lack of resources, segmentation
>>fault, or whatever), DSS Admin reports those streams until the 60 second
>>timeout elapses, after which it cleans them up. When we select
>spampro.conf
>>to "loop", failed clients can get restarted, resulting in a temporary
>>erroneous stream count (DSS reports more streams than could possibly be
>>playing), but the apparent severe undercounting of streams by DSS Admin is
>a
>>mystery.
>>
>>When SpamPro exits, we get a completed "spam.log" file which also has
>>interesting results:
>>"
>>Client Complete. IP addr = ..., URL=...
>>"
>>Most lines indicate the client completed "normally", but the packets
>>received number, and bandwidth numbers, are only half (or less) the
>expected
>>number on some clients. There are no port numbers associated with clients
>>(in the spam.log file), so there is no practical way to examine an ethernet
>>capture trace to determine exactly how many packets actually made it across
>>the wire. QTFileInfo tells you how many RTP packets to expect (for audio,
>>video tracks) for the hinted file, and many clients report this number as
>>expected. How can some clients report half as many with no indication of
>>errors or lost frames? Is it the result of "thinning"?
>>
>>We have also run the test code for .rtp files (packets on disk). In this
>>case, we get numerous errors with:
>>"
>>Client Complete. IP addr = ..., URL=.../spampro.mov.rtp
>>Connection Status: Disconnected while playing.
>>"
>>We tried to disable disconnect logic in the xml config files (by setting
>>very large maximum_connections, maximum_bandwidth, safe_play_duration 0,
>>etc). Is there anyway to debug the reason for disconnection? (This
>happens
>>with more than 50% Idle CPU and plenty of available memory for DSS.)
>>
>>Also,
>>"
>>Connection status: Failed RTSP request. Failed request status: 415
>>"
>>If this status follows the codes from RTSP specs (RFC 2326, April '98, sec
>>7.1.1), 415 is "Unsupported Media Type". This seems bogus since hundreds
>of
>>streams with the same URL were opened and completed normally.
>>
>>Can anyone shed light on these questions? Is there any FAQ or
>documentation
>>on SpamPro? Will the source for SpamPro ever be opened? Are there any
>>reliable open tools with similar functionality to SpamPro?
>>
>>Thanks,
>>Don
