Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

ANN: snuffstream

 [1/5] from: maarten:vrijheid at: 8-Mar-2004 21:26


Async http 1.0 file server for progressive downloads of divx, mp3, MPEG-2: http://www.surfnetters.nl/maarten/snuffstream.zip As little as 259 kB it gives little load on your system when sending out multiple divx's and mp3's. Linux version will follow. From the README: What is snuffstream? Snuffstream is a simple http 1.0 server that supports GET requests. Its main purpose is serving large files, very very fast with little impact on your system. I wrote it cuz I wanted to view 6mbit MPEG-2 (DVD) easily, but it works for all kinds of files. You can adapt config.r for your local "media" base directory and add different mime types if you like. You can also change the default port on which it listens in config.r, and the default mime-type. It should also work for serving static html files and all sorts of other content. I tested it with Quickime 6.5, WM 9, VLC 0.7.0 (www.videolan.org, *really* th ebest player) and Mozilla and IE. Technically speaking it is not streaming but progressive download what it does as it uses HTTP 1.0. Depending on the player/filetype you may get a progressive download or a normal download. VLC seems to do progressive very good. With QT and WM your mileage may vary. Start watching/listening/... today! --Maarten

 [2/5] from: andreas::bolka::gmx::net at: 10-Mar-2004 13:39


Monday, March 8, 2004, 9:26:57 PM, Maarten wrote:
> Async http 1.0 file server for progressive downloads of divx, mp3, > MPEG-2: http://www.surfnetters.nl/maarten/snuffstream.zip > As little as 259 kB it gives little load on your system when sending > out multiple divx's and mp3's.
Wow! I must confess, I'm impressed! To summarize my first experiences: Snuffstream performs reasonably good, in fact it performs so good, that measuring it against Apache made sense. Considering Snuffstream's size, it's memory and CPU usage while running I'm inclined to say that is a very interesting product, although I'm (obviously) not yet able to tell about long-time performance or various issues that may arise in "real world" deployment. From what I can tell at the moment, I consider Snuffstream a viable HTTP server for static file serving purposes, especially when a personal server (e.g. running on your "desktop" machine) is required. It's a serious competitor to established products in this sector, especially when we consider Snuffstream's "just drop it somewhere" installation. Further, due to it's size and reasonable performance, embedding Snuffstream in custom applications that require static HTTP file serving seems to be an obvious fit. Finally, Snuffstream seems to be _very_ suited for it's marketed purpose, namely as VLC server. Once I have more data on long-time stability, I'll report again :) Finally, some test results that lead me to above conclusions: 1) Downloading a 481 MB file first with wget and then with Firefox. Snuffstream: - wget: download at 5.38 MB/s - Firefox: download at roughly 4.0 MB/s - Both: the process's CPU usage stays between 2% to 10% - Both: process size keeps constantly at around 5 MB Apache: - wget: download at 7.58 MB/s - Firefox: download at roughly 3.9 MB/s - Both: CPU usage at 0% - Both: process size total (2 processes) at around 6.5 MB 2) Simulated load requesting a 9 byte .txt file. Snuffstream's config.r has been modified to serve *.txt as text/plain. 2.1) 1 worker, 100 sequential requests: - snu: 150 req/sec, 6.8 ms avg time per req - apa: 400 req/sec, 2.6 ms avg time per req 2.2) 2 parallel workers, 100 sequential requests each: - snu: 150 req/sec, 13.3 ms - apa: 400 req/sec, 4.9 ms 2.3) 10 parallel workers, 10 sequential requests each: - snu: 150 req/sec, 67.0 ms - apa: 380 req/sec, 25.0 ms 2.4) 50 parallel workers, 2 sequential requests each: - snu: 100 req/sec, 500.7 ms - apa: 200 req/sec, 250.3 ms 3) Simulated load requesting a 3 KByte .gif file. Snuffstream and Apache are both configured to serve this as application/octet-stream. 3.1) 1 worker, 100 sequential requests: - snu: 150 req/sec - apa: 400 req/sec 3.2) 10 parallel workers, 10 sequential requests each: - snu: 144 req/sec - apa: 380 req/sec My test setup: A P4-M 1.6, 512 MB RAM, 7200 RPM IDE HDD, WinXP SP1. Snuffstream version as avail from Maarten's site, Apache 2.0.48, downloads using GNU Wget 1.8.2 and Mozilla Firefox 0.8. Load tests using a slightly customized version of ApacheBench Version 2.0.40-dev (Revision: 1.120, apache-2.0). Disclaimer: These tests make no scientific claim. Test setup information is provided for informal purposes. -- Best regards, Andreas

 [3/5] from: maarten:vrijheid at: 10-Mar-2004 14:08


Wow!! Thanks for the great tests. Now what I will improve is caching. Presently there is no in-memory cache, that is why the numbers are pretty constant, I guess. I'll try to fiddle with it some more. With large files it surely works nicely for a "media" http server. You know that I have been wanting to integrate this with presence (IM) and I hope to base that on MSN, so you can watch/listen from your buddylist (only). Given these figures it is reasonable to expect this to work on an average system. --Maarten Andreas Bolka wrote:

 [4/5] from: antonr:iinet:au at: 11-Mar-2004 0:30


I appreciate the time taken to make these tests Andreas, and Maarten, well, you're just too good to be true. Anton.

 [5/5] from: greggirwin:mindspring at: 10-Mar-2004 12:52


AR> I appreciate the time taken to make these AR> tests Andreas, and Maarten, well, you're just AR> too good to be true. I'd like to second and third that! Very much appreciated! -- Gregg