| But if you do it one thread/connection, then as the load on the server
| increases, it's *still* just one process as far as Unix's accounting goes.
| So the net effect is that the cycles provided by a single process just
| get divided up into smaller and smaller slices by the clients w/o increasing
| the load on the system.
That's wrong, I think. Unix processes are cheap and efficient. User
mode threads are expensive, inefficient, and hard to get right. In an
ftp daemon, all those bytes have to go thru the kernel to get out to
the network, one way or another. Smooshing them together in one
process with lots of sockets open doesn't reduce that burden at all,
but it does add the expense of duplicating in user mode the mechanisms
that the kernel provides directly to normal processes.
Accounting is irrelevent; it doesn't measure efficiency or thruput
or very much of interest (which is kind of a shame if you are into
measuring performance, sigh).
| Naah. I imagine an ftp server is primarily I/O bound.
Currently they are I/O bound. Add a huge interpreter in there and
let's see what happens. If you don't take advantage of scheme's
features, then why bother recoding in the first place?
(Analogy: reading news is I/O bound, except that I used emacs to
do it. :-)
| And the next release
| of scsh (I hope) will have mechanisms for linking the initial image into the
| VM's text pages. So the heap's will be small, and the byte codes will be
| (a) shared between processes, and (2) unscanned by the GC.
That will help some, but I still wish all those myriad pages
weren't necessary at all.
|