[icecast-dev] icecast2 ogg vorbis client request headers

[Likai Liu]

On Sun, 4 Apr 2004, oddsock wrote:

> quick and dirty I ran the following 2 programs :
> and got the following results :
> 
> /usr/home/oddsock/tmp-> time forkit > /dev/null
>     5.13s real     1.82s user     3.27s system
> /usr/home/oddsock/tmp-> time curlit > /dev/null
>     0.76s real     0.14s user     0.18s system
> 
> so as far as performance goes, the HTTP request seemed to outperform in the
> simple/quick case.

That is on a Unix system?

> from what I know, process creation is extremely expensive, much more so that
> thread creation.

It depends on what kind of thread you're talking about, and on what
system. On Windows, this is generally true. On Linux, linux threads that
use the clone system call are just as expensive as processes (they show up
as processes too). User space threads that use setjmp/ucontext are cheap
(they're "fibers" in Windows call, I believe).

> Which is why I thought properly tuned apache installs are
> not configured to fork for each request.

Well, if it's better to avoid thread creation algether, what about a
single threaded, multiplexed I/O web server?

> since we would use libcurl for making HTTP requests, it supports http
> keep-alive requests...and so yes, persistent HTTP connections ARE possible.
> 
> > This approach also lets you get the http-request approach 'for free' - you
> > just provide a script that does an HTTP request to some URL and returns the
> > appropriate value.
> 
> hardly 'for free' and this would be a horribly inefficient method of doing it.

I think the hope is that one could amortize the cost because (1) 
connections to a media streaming server aren't supposed to be made 
frequently, (2) the authentication process (parsing a database file, etc) 
would take a while, or (3) authentication over the network is subject to 
network latency.

I was going to suggest if efficiency is a very important issue, one should
use shared library for authentication, but then you probably don't want to
deal with all the different kinds of shared libraries on systems, DLL on
windows, *.so for sane Unix, and *.dylib versus bundles on Darwin/Mac OS 
X. And I hate libtools...

It would possibly be useless for most users too, but it does take all the 
authentication logic outside of icecast, and it's efficient enough.

liulk
--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.