Yes, on Linux and FreeBSD (which would be closer to "on topic", I suppose), but others do get a boost now: Win*, Solaris, and NetWare at least. I cannot speak to Zeus's flexibility, but you seem to like it a lot, so I may try it out (but unfortunately it is in a large stack of "side" projects). Even if I don't "like" it so much, if it is as efficient as you say, and not a PITN configuration-wise, I might want to use it as a light weight 1st stage server. Is that an easy task with Zeus? How well does it integrate with Perl? ;-) Troy >>> david at acz.org 10/29/03 02:03PM >>> Yes. On most popular free UNIX operating systems (Linux, FreeBSD), there is little difference between a process and a thread. In fact, on Linux (at least up through 2.4), threads are implemented as processes (i.e. LinuxThreads). It is theoretically possible for the performance of a preemptive thread based model to approach that of state threads model, but it doesn't work that way in practice right now. Here are a few interesting pages: http://www.kegel.com/c10k.html http://www.freebsd.org/kse/ http://cr.yp.to/lib/npthread.html http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html http://www.monkey.org/~provos/libevent/ > I think 1.3.x may be harder to "scale" upwards than some solutions, > but for me it more than makes up for that in flexibility (which can > also sometimes be a downside too, I know). I don't consider Apache to be any more flexible than Zeus. You can write modules for Apache and ISAPI filters for Zeus. There are nice features unique to both pieces of software, obviously, but Apache certainly does not have a monopoly on flexibility. > But when you say "not > scalable", I ask where the hard chalk line is drawn between > the worlds of "scalable" and "not so". I meant it in the sense of O(1) versus O(n). > A nitpick, maybe, and it is > simply your opinion, sure, but my opinion is that many folks find > the old and crusty Apache 1.3.x multiprocess model "scalable > enough". As I said, for most people, Apache is quite adequate. The original poster was having configuration difficulties. I gave him a recommendation based on years of experience working with web servers. Two people disagreed with that suggestion based on documentation that was likely written years ago, which addresses concerns that are not relevant to at least 99% of people running Apache, and certainly not relevant to the original poster. Hence my response about Apache's performance. Summary: If you are running CGI scripts on a process-per-connection web server, a few cached OS calls are the least of your performance worries. -- David Phillips <david at acz.org> http://david.acz.org/ _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list _______________________________________________ TCLUG Mailing List - Minneapolis/St. Paul, Minnesota http://www.mn-linux.org tclug-list at mn-linux.org https://mailman.real-time.com/mailman/listinfo/tclug-list