Slashdot Mirror

In a part about databases and persistent connections they confuse the issues more than a bit. The real problem is not too many processes, what automatically makes threads look better, but the symmetry among processes -- any request should be possible to serve by every process, so all processes end up with database connections. This is a problem particular to Apache and Apachelike servers, not a fundamental issue with processes and threads.

In my server (fhttpd I have used the completely different idea -- processes are still processes, however they can be specialized, and requests that don't run database-dependent scripts are directed to processes that don't have database connections, so reasonable performance is achieved if the webmaster defines different applications for different purposes. While I didn't post any updates to the server's source in two last years (was rather busy at work that I am leaving now), even the published version 0.4.3, despite its lack of clustering and process management mechanism that I am working on now, performed well in situations where "lightweight" and "heavyweight" tasks were separated.

One of the goals of my fhttpd server design was to separate the model of request processing in the backend from internals of HTTP server itself, and the examples in my previous messages are running on custom backends written for fhttpd -- webcams are always six processes without any additional threads (three processes per camera -- one process talks to http server, one talks to the camera, one compresses jpegs -- the program is released as qcwebcam), and X-10 is handled by a single process (also with no threads involved) that handles everything and talks to X-10 "modem" through a serial port.

One of the goals of my fhttpd server design was to separate the model of request processing in the backend from internals of HTTP server itself, and the examples in my previous messages are running on custom backends written for fhttpd -- webcams are always six processes without any additional threads (three processes per camera -- one process talks to http server, one talks to the camera, one compresses jpegs -- the program is released as qcwebcam), and X-10 is handled by a single process (also with no threads involved) that handles everything and talks to X-10 "modem" through a serial port.

There are a lot of things other than CGI that can be used on HTTP servers -- most servers have either their own scripting language, or C API. The problem with most of those things is that most of scripting langages are limited, and most of C API are either complex or unsafe (run in server's address space and can cause all kinds of trouble if program misbehaves). I have designed my own API for fhttpd, trying to avoid both problems, and IMHO the result is usable.

fhttpd FTP/HTTP server that I wrote has its own interface with php. It allows things like configuring sets of php scripts to run under different userids, make pools of processes that use some limited resources like database connections and some others. php3 is supported as a module, and I am porting the interface to php4, so at the time of php4 release it will be supported as a module, too.

My fhttpd with combination of MySQL and PHP can be considered, too -- it allows some configuration options and optimizations that Apache doesn't provide -- you can limit the number of connections to database, use separate userids for sets of scripts, etc. If you want even more performance, program in C or C++ can be written as its module, and the API is much easier to use than one of Apache.

My fhttpd with combination of MySQL and PHP can be considered, too -- it allows some configuration options and optimizations that Apache doesn't provide -- you can limit the number of connections to database, use separate userids for sets of scripts, etc. If you want even more performance, program in C or C++ can be written as its module, and the API is much easier to use than one of Apache.

It takes about up to 1 fps at 320x240, 24-bit color or up to 4 fps 6-bit B&W of the same size, has parallel interface (I was able to use up to 3 per box with additional parallel interfaces on the card), and it works with Linux and FreeBSD. See http://www.fhttpd.org/pub/qcwebcam/R EADME.html, http://phobos.illtel.denv er.co.us/~abelits/apartment.php3 for an example and http://phobos.illtel.denver.co.us/qca m-config for controls page.

It's possible to modify the code to increase the resolution, however this kind of camera has twice higher resolution for green component than for red and blue ones, so even though picture will be 640x480 it won't be the same thing as real 640x480.

Finally, please, if any of you HAVE run a web cam off a linux box, please, do email. Any other questions, comments, suggestions, whatever, just send 'em my way.

I use QuickCam, and it works through parallel port, however the speed is limited to about 1fps at 320x240 24bpp resolution AND it takes a lot of processor time because of stupid parallel port interface design. Still it should be usable on a box like that.