Date: Fri, 16 Jul 1999 00:06:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: unknown@riverstyx.net (Tani Hosokawa) Cc: tlambert@primenet.com, davids@webmaster.com, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907160006.RAA15994@usr07.primenet.com> In-Reply-To: <Pine.LNX.4.10.9907151200240.10288-100000@avarice.riverstyx.net> from "Tani Hosokawa" at Jul 15, 99 12:10:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > The current model is a hybrid thread/process model, with a number of > > > processes each with a large number of threads in each, each thread > > > processing one request. From what I've seen, 64 threads/process is about > > > right. So, in one Apache daemon, you can expect to see >1000 threads, > > > running inside 10-20 processes. Does that count as a large number? [ ... ] > Thank you for spewing some geek-speak into an unrelated discussion. I > welcome you to bring forth a new webserver that can duplicate everything > that Apache can do with the same developer support that Apache has using a > different model. You, yourself, indicated that the process architecture was in flux; if so, then it would be a good idea if it got away from threads dependencies before it solidifies to something that won't run at all on some platforms. > Hey, maybe if can be done. Certainly, if what you say is true (I don't > dispute the technical merits, since I don't know enough about them) a > webserver can be built like that. However, the question that begs to be > answered here is "Will you do it?" And the answer, in all likelihood, is > "no". I believe the Zeus server, which the Linux folks were complaining was not being tested by Mindcraft (instead of Apache) supports this model, since it requires the ability to do clustering, and migrating a thread across machines is computationally hard. > So, what we get back to is, what's one thing that's wrong with FreeBSD? > Threads. That's actually "what's wrong with applications?". The closest you can get to blaiming FreeBSD for this is "why can't FreeBSD run these applications that rely on threads in an SMP scalable way?". I could easily ask a similar question: "why can't FreeBSD run Microsoft Office 2000?". > Does it matter whether some other model has "the potential" to beat Apache > in performance? No. People aren't going to switch to this new webserver > at the drop of a hat, because Apache's a really nice, flexible webserver, > that we've already torture-tested for years, and we're already familiar > with it. It matters if the Apache process architecture is in flux, and can be affected in such a way as to not unneccessarily preclude having good performance on dozens of platforms for the benefit of having good performance on a single platform that happens to be the current benchmark target. > You want to simply ignore the fact that a webserver with over 50% of the > world's market share happens to require threads just because in your > opinion the developers of said webserver have their heads up their ass as > far as programming is concerned? I didn't say that. Far from it. I admire them greatly, first and foremost for the first trans-core-team free software project to arise. I admire their coding skills, and their understanding of their target problem. But requiring threads in a supposedly high performance application is going to result in your performance varying wildly between platforms. I believe it is something they will have to backpedal on, if not done abstractly. I fully believe, for example, that FreeBSD's user space threading can be brought to a point where it is (1) SMP scalable, without significant kernel work, and (2) lower overhead than even Solaris' hybridized cooperated scheduling. This would mean Apache, threaded, would run very well on FreeBSD, slightly less well on Solaris, less well than that on SVR4.2, slower still on NT, and yet slower on Linux. Given this, it would still be my assessment that depending on a single concurrency model for all target platforms, instead of abstracting the concurrency model to allow platform specific optimizations (_effective_ platform specific optimizations), yes, is "still a bad idea". > That's naive. Especially when you're talking about development > on what's supposedly a "server OS". Server != threads. > The question that people are asking when they consider platforms is not > "if we were going to write our own software product, what OS would we > choose, if we were to adopt the most efficient paradigm?", it's "what OS > will give us the best performance if we're going to use X established > existing software product?" The cross-platform engineering projects I have been involved in have been very conscious of isolating the platform dependencies from the code to allow for platform specific optimization. Even given the existance of the evil "configure" program I really doubt the Apache people aren't (very) wise to this. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907160006.RAA15994>