David Phillips wrote: > Troy.A Johnson writes: > >>I am not "freaking out" > > > That was not directed at you, but rather people who know little about web > servers and assume Apache is the best web server available simply because it > is the most popular. > > >>Do the same limitations apply to the Apache 2.0.x series? > > > 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). This is perhaps because process task switches are _already_ so optimized that there is little perfomance gain left to be had by going to a threaded model? Perhaps Apache using a task-per-connection model is _more_ scalable than a lot of other potential solutions, as well as being easier to code and debug than a threaded server? The only compelling reason I've seen for multithreaded development on Linux is it works better for GUI programs and others that need to deal with stateful processing of wildly differing IO and compute channels cleanly. Especially GUI games on SMP systems. Yumm! > > 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/ > After a quick looksee, I don't see how any of these really relate. Yeah, perhaps Apache, or ANY OTHER SIMILAR webserver will run out of resources with a large number of simultaneous connections, but that is not the only measure of "best". > >>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). > Then you are talking out your ass. I disbelieve in this mythical O(1) webserver of yours. I even doubt you can get O(logn). > >>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. > For _most_ people, Apache is so far beyond what they need it is unbelievable. The number of sites that are likely to run into Apache-specific scaling problems probably number in the dozens. Sites that do dynamic script-generated content run into scaling problems (/. for instance), but these are often fixed by improving the scripts or backend databases. cdrom.com is a _major_ download site serving up multi-megabyte files by the hundreds to the whole world. Of _course_ they would need the most scalable solution they can get. No fat on that site. > 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. > Which is at least as irrelevant, if not more so. > 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. > And your choice of webserver is also the least of your worries. Really. _______________________________________________ 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