Re: [community] 2.3.0 alpha on October 1?
William A. Rowe, Jr. wrote on 2008年8月22日 9:03:
Which brings me to the other half of [community], I'm proposing we hold
an Apache httpd {next} barcamp session for the community who are at
ApacheCon BarCamp on Tuesday to learn about what has changed, what might
change, and perhaps if we get enough folks to express interest ... about
what they want to change.
Another related question: We haven't been able to build httpd on 64-bit
Windows for about two and half years, since the April 2006 release of
httpd-2.2.2 (But x64 build is crucial for our application, and that's why we
are still using that aged version). Shall we have 64-bit Windows release
in the near future, say 2.2.10? (btw, we are really delighted to see that
now APR has a *clean* compile on x64 Windows.)
Bing
School of EE CS,
Peking University,
Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
Jorge Schrauwen wrote on Sunday, September 14, 2008 7:47 PM This is no true. The latest version I've been able to compile was 2.2.9 http://www.blackdot.be/?inc=apache/binaries You are however correct that it's getting more cumbersome! Vista + VS 2005/2008 is a no go. I'm using a XP x64 with VS 2005 in vmware to build it now. Also command line building is busted Using the IDE it's still possible. We have to use Visual Studio 2005 plus Windows Server 2003 R2 x64 (SP2) and Windows 2008. We couldn't build it using the IDE with the version macro _WIN32_WINNT=0x0500 or 0x0600. (However, the APR part can be compiled cleanly.) Bing
Re: [community] 2.3.0 alpha on October 1?
Bing Swen wrote:
William A. Rowe, Jr. wrote on 2008年8月22日 9:03:
Which brings me to the other half of [community], I'm proposing we hold
an Apache httpd {next} barcamp session for the community who are at
ApacheCon BarCamp on Tuesday to learn about what has changed, what might
change, and perhaps if we get enough folks to express interest ... about
what they want to change.
Another related question: We haven't been able to build httpd on 64-bit
Windows for about two and half years, since the April 2006 release of
httpd-2.2.2 (But x64 build is crucial for our application, and that's
why we are still using that aged version). Shall we have 64-bit
Windows release in the near future, say 2.2.10? (btw, we are really
delighted to see that now APR has a *clean* compile on x64 Windows.)
I don't even see the need to wait for 2.2.10. It's a matter of deciding
what httpd is bound to. msvcr71? 80? 81? 90? msvcrt? There are arguments
for each of these cases. I've actually put the question of recycling and
combining binary artifacts to MS Visual Studio engineers, face to face.
The response so far is a puzzled look (of why would you want/need/care
to do that?) and no solution appears in sight, but they did take note that
some of us are increasingly frustrated with the mess this creates.
The same question will apply to 2.4.0 when it's time to roll those binaries.
Thoughts and opinions?
Re: [community] 2.3.0 alpha on October 1?
(Speaking of pet peeves -- why does Apache handle so many things besides HTTP, and yet I have to get other servers to handle certain kinds of HTTP requests because Apache doesn't handle it well?) 100K concurrent requests, kept open.
Re: [community] 2.3.0 alpha on October 1?
Our latest builds, on some fairly modest hardware, are actually about twice as fast as numbers I posted last time async-vs-threads came up. Apache can very easily fill multiple gigE interfaces on modest hardware. We can sustain about 45k requests/sec on our build on a dual dual-core system with a network card that supports Linux NAPI (that made a huge difference). Without much tuning 35k is pretty easy. (Note: this was very small files, bcs it's so easy to fill the network interfaces). Filling gigE and requests/sec aren't targets that concern me as a user. They sound like nice beanchmarks though... Latency is another story, so keeping connections open for 15minutes at a time, and spoon feeding small bits of content quickly is more important (for me). I guess that is why comet servers have come into existence. Perhaps I just need to deal with the fact that we need multiple kinds of HTTP servers. (Speaking of pet peeves -- why does Apache handle so many things besides HTTP, and yet I have to get other servers to handle certain kinds of HTTP requests because Apache doesn't handle it well?)
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote on 2008年9月3日 7:54 Egads, no wonder they got such horrible performance. Worker (or event, maybe) seems to be the best way to go, at least based on our testing. Yes, Worker can work much better, but seems to be basically the same order of magnitute as threads on Windows (still far more less scalable in terms of concurrent connections than Nginx). Maybe you have super-optimized hardware and system? ... We run internal benchmarks often and collect a lot of performance statistics from live traffic (response times, etc.) We also, however, do not run any vendor supplied httpd build, either. RedHat's, for example, is not for production websites, IMO. So I wonder perhaps next time you guys may bother to take time to also run Nginx on your platform and tell us how it performs against your httpd build... Bing Bing Swen (孙斌) School of EE CS, Peking University, Beijing 100871 Tel：86-10-62753081 ext 102 Fax: 86-10-62759444 [EMAIL PROTECTED]
Re: [community] 2.3.0 alpha on October 1?
On 9/4/08 4:22 AM, Bing Swen [EMAIL PROTECTED] wrote: Maybe you have super-optimized hardware and system? Nope, standard off the shelf systems. So I wonder perhaps next time you guys may bother to take time to also run Nginx on your platform and tell us how it performs against your httpd build... Will do. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [community] 2.3.0 alpha on October 1?
On 9/4/08 2:54 AM, steve [EMAIL PROTECTED] wrote: Filling gigE and requests/sec aren't targets that concern me as a user. They sound like nice beanchmarks though... To some folks, filling a gigE is important. FWIW, I ran some tests yesterday with about 50K ISDN (384K) speed clients and httpd and the system was still very responsive. Will try to do some ~ 56k tests if I have time today. (Speaking of pet peeves -- why does Apache handle so many things besides HTTP, and yet I have to get other servers to handle certain kinds of HTTP requests because Apache doesn't handle it well?) Any particular requests you'd like to address here? -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [community] 2.3.0 alpha on October 1?
William A. Rowe, Jr. wrote: bill stoddard wrote: I completely agree, it's not a slam-dunk conclusion that async/event driven connection management in an http server is clearly superior. However, Bing mentioned Windows... Apache on Windows is not a stellar performer, especially compared to a server that fully exploits IOCPs, connection reuse and TransmitFile. The Windows MPM does use IOCPs (not optimally) and connection reuse. The biggest inhibitor to Apache on Windows performance serving files is in the apr_sendfile implementation. Calls to TransmitFile are broken into something like 64KB chunks in order to facilitate detecting send timeouts. If you modify the call to TransmitFile to always just send the whole file, performance sending large files will improve dramatically. My current thinking goes as follows; * drop detecting timeouts in apr_sendfile (if win32 is incapable, so be it, they can configure sendfile off if they must, and in fact we could do so by default, solving all sorts of NFS-issues with it.) +1 - Will review. * drop win32acceptex semantics, replace them with acceptfilter... none (a simple accept), connect[ion] (the acceptex semantic), data (acceptex enhanced with first buffer). I don't see the advantage of dropping acceptex. AcceptEx allows reuse of the connection which saves some cycles. Is it breaking anything now? Bill
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote: On 9/2/08 3:15 PM, bing swen [EMAIL PROTECTED] wrote: It seems the test (done by another guy) indeed used an everything plus the kitchen sink default Apache httpd at first, but then dropping off 3/4 of all of the default modules (maybe not that much, but only for serving static pages) seemed to have a not big help. The MPM used the default configuration (prefork on Linux and threads on Windows). [not your settings?] Egads, no wonder they got such horrible performance. No kidding :-) Worker (or event, maybe) seems to be the best way to go, at least based on our testing. People who do performance benchmarks on Linux with default config and prefork are careless at best. Yep, if your testing how well Apache handles concurrent connections, you must use worker (thread per connection dispatch model with known production quality on multiple platforms, windows excluded) or event (works well on some platforms but maybe not fully vetted on many platforms). That said, it is possible to hand craft benchmarks to demonstrate any particular 'feature' of the code your showing off. Whether those hand crafted benchmarks are realistic is another matter entirely. Bill
Re: [community] 2.3.0 alpha on October 1?
On 9/1/08 8:11 AM, Jim Jagielski [EMAIL PROTECTED] wrote: On Aug 31, 2008, at 9:49 AM, Bing Swen wrote: To my knowledge, the one thread per connection network i/o model is a suboptimal use threads vs. events is certainly not, imo, a finalized debate yet with a known winner or loser. Maybe 5-10 years ago events had a clear advantage but today that is hardly the case... I have documented my vote on this in the past, but the async is inherently faster looks good on paper, but does not, IMNSHO, measure up in the real world. It seems that lighttpd, and others, simply come with a much more realistic default configuration out of the box. Our latest builds, on some fairly modest hardware, are actually about twice as fast as numbers I posted last time async-vs-threads came up. Apache can very easily fill multiple gigE interfaces on modest hardware. We can sustain about 45k requests/sec on our build on a dual dual-core system with a network card that supports Linux NAPI (that made a huge difference). Without much tuning 35k is pretty easy. (Note: this was very small files, bcs it's so easy to fill the network interfaces). Apache is slow is just FUD, plain and simple. We need to work on getting things like x-sendfile into stock distribution and pushing the use fastcgi for php type things into the documentation. (Sorry, put this area is one of my pet peeves.) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote on Tuesday, September 02, 2008 11:31 PM: sustain about 45k requests/sec on our build on a dual dual-core system with a network card that supports Linux NAPI (that made a huge difference). Without much tuning 35k is pretty easy. (Note: this was very small files, bcs it's so easy to fill the network interfaces). Apache is slow is just FUD, plain and simple... There is a little different viewpoint. According to some recent test reports comparing Apache 2.2 and Nginx 0.6/0.7 (from a blog website admin.), Apache could do as well as Nginx when there are a few connections each of which carries many many requests. The hard time for Apache came when there are many *slow connections*, each of which sends only a few small requests at large durations. In such condition, Apache could hardly respond when the no. of connections reached over 3,000 (even when there is still much free memory). By contrast, responses from Nginx kept full speed even with 10 times more connections. It seems only to slow down when it runs out free memory, but not limited by concurrent connections. (The same is true for Apache on Win.Server '08. But I guess the Linux version might not have Linux NAPI support.) Such slow connection issue happens to be the typical scenario of video, chat or blog authoring websites. No wonder they are willing to put aside their familiar Apache just for cutting off the budget. So it makes sense to concern whether Apache needs improving over this problem. If so, the only question is how;) Bing School of EE CS, Peking University, Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote: On 9/1/08 8:11 AM, Jim Jagielski [EMAIL PROTECTED] wrote: On Aug 31, 2008, at 9:49 AM, Bing Swen wrote: To my knowledge, the one thread per connection network i/o model is a suboptimal use threads vs. events is certainly not, imo, a finalized debate yet with a known winner or loser. Maybe 5-10 years ago events had a clear advantage but today that is hardly the case... I have documented my vote on this in the past, but the async is inherently faster looks good on paper, but does not, IMNSHO, measure up in the real world. I completely agree, it's not a slam-dunk conclusion that async/event driven connection management in an http server is clearly superior. However, Bing mentioned Windows... Apache on Windows is not a stellar performer, especially compared to a server that fully exploits IOCPs, connection reuse and TransmitFile. The Windows MPM does use IOCPs (not optimally) and connection reuse. The biggest inhibitor to Apache on Windows performance serving files is in the apr_sendfile implementation. Calls to TransmitFile are broken into something like 64KB chunks in order to facilitate detecting send timeouts. If you modify the call to TransmitFile to always just send the whole file, performance sending large files will improve dramatically. There is also a difference between async i/o and event driven i/o. The former requires more discipline managing buffers across the async i/o calls. Windows supports true async network i/o; many unix distros do not. IMO, event driven is good enough. async introduces too much complexity for questionable benefit. Bill
Re: [community] 2.3.0 alpha on October 1?
On 9/2/08 1:02 PM, bing swen [EMAIL PROTECTED] wrote: There is a little different viewpoint. According to some recent test reports comparing Apache 2.2 and Nginx 0.6/0.7 (from a blog website admin.), Apache could do as well as Nginx when there are a few connections each of which carries many many requests. The hard time for Apache came when there are many *slow connections*, each of which sends only a few small requests at large durations. In such condition, Apache could hardly respond when the no. of connections reached over 3,000 (even when there is still much free memory). I saw this comparison somewhere. It just does not seem to match what I have seen. Our little ole website has been known to take a few connections from slow clients, but we have not really seen this slow down. I'd like to see more specifics of the test. All of my numbers are from real world stuff. (FYI, NAPI is just a way which Linux handles NIC irq's better - a gross simplification, but it makes a huge difference on very busy web servers. I'm sure other OS's have something similar?) -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [community] 2.3.0 alpha on October 1?
Akins, Brian wrote on Wednesday, September 03, 2008 2:07 AM I saw this comparison somewhere. It just does not seem to match what I have seen. Our little ole website has been known to take a few connections from slow clients, but we have not really seen this slow down. I'd like to see more specifics of the test. All of my numbers are from real world stuff. It seems the test (done by another guy) indeed used an everything plus the kitchen sink default Apache httpd at first, but then dropping off 3/4 of all of the default modules (maybe not that much, but only for serving static pages) seemed to have a not big help. The MPM used the default configuration (prefork on Linux and threads on Windows). [not your settings?] (FYI, NAPI is just a way which Linux handles NIC irq's better - a gross simplification, but it makes a huge difference on very busy web servers. I'm sure other OS's have something similar?) Maybe that was a big difference. (The default Linux didn't provide such feature.) But it might have limited help for greatly increasing the connection number. Bing School of EE CS, Peking University, Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
bill stoddard wrote: I completely agree, it's not a slam-dunk conclusion that async/event driven connection management in an http server is clearly superior. However, Bing mentioned Windows... Apache on Windows is not a stellar performer, especially compared to a server that fully exploits IOCPs, connection reuse and TransmitFile. The Windows MPM does use IOCPs (not optimally) and connection reuse. The biggest inhibitor to Apache on Windows performance serving files is in the apr_sendfile implementation. Calls to TransmitFile are broken into something like 64KB chunks in order to facilitate detecting send timeouts. If you modify the call to TransmitFile to always just send the whole file, performance sending large files will improve dramatically. My current thinking goes as follows; * drop detecting timeouts in apr_sendfile (if win32 is incapable, so be it, they can configure sendfile off if they must, and in fact we could do so by default, solving all sorts of NFS-issues with it.) * drop win32acceptex semantics, replace them with acceptfilter... none (a simple accept), connect[ion] (the acceptex semantic), data (acceptex enhanced with first buffer). I'll be committing this over the next few weeks, but I'd love review and feedback on the ideas. Migrating the first discussion over to apr in the next day or so. Bill
Re: [community] 2.3.0 alpha on October 1?
On 9/2/08 3:15 PM, bing swen [EMAIL PROTECTED] wrote: It seems the test (done by another guy) indeed used an everything plus the kitchen sink default Apache httpd at first, but then dropping off 3/4 of all of the default modules (maybe not that much, but only for serving static pages) seemed to have a not big help. The MPM used the default configuration (prefork on Linux and threads on Windows). [not your settings?] Egads, no wonder they got such horrible performance. Worker (or event, maybe) seems to be the best way to go, at least based on our testing. People who do performance benchmarks on Linux with default config and prefork are careless at best.We run a fairly full featured config, but try to be smart about it. We run internal benchmarks often and collect a lot of performance statistics from live traffic (response times, etc.) We also, however, do not run any vendor supplied httpd build, either. RedHat's, for example, is not for production websites, IMO. -- Brian Akins Chief Operations Engineer Turner Digital Media Technologies
Re: [community] 2.3.0 alpha on October 1?
Bing Swen wrote: Although Apache is famous for its modular design and configuration flexibility, it seems these new comers are challenging the relevance of Apache in real use. Is there any chance for Apache to get much better performance while retaining its design beauty? No, and yes. No, there's very little chance that anyone will randomly attack the poor perfomance before 2.3.0 alpha, and the rule of open source software is that the one with an itch to scratch is the one who will author and offer the patch. Maybe that's you :) And yes, httpd quite possibly approaches their performance if you drop off 3/4 of all of the default modules. Especially if it's tuned to use the event mpm and sendfile. And finally, yes; httpd 2.4/3.0 is likely to offer (not always use, some modules will be foreever incompatible) a truly async mode of operation. That is, with the current enhanced poll semantics (about 5 different flavors across 4 major OS's) there's no reason not to park workers with nothing to do right now away from any worker thread. But I'd challenge you to configure nothing but the bare minimum modules which solve your configuration and *then* post some notes about performance. If you are comparing an everything plus the kitchen sink default Apache httpd to a far more featureless server, there's really nothing we can tell you other than the features suck CPU. Bill
Re: [community] 2.3.0 alpha on October 1?
On Aug 31, 2008, at 9:49 AM, Bing Swen wrote: To my knowledge, the one thread per connection network i/o model is a suboptimal use threads vs. events is certainly not, imo, a finalized debate yet with a known winner or loser. Maybe 5-10 years ago events had a clear advantage but today that is hardly the case... Not saying that httpd shouldn't (or won't) have an true event driven MPM, but it is hardly the manna the masses claim it to be.
Re: [community] 2.3.0 alpha on October 1?
Jim Jagielski wrote: On Aug 31, 2008, at 9:49 AM, Bing Swen wrote: To my knowledge, the one thread per connection network i/o model is a suboptimal use threads vs. events is certainly not, imo, a finalized debate yet with a known winner or loser. Maybe 5-10 years ago events had a clear advantage but today that is hardly the case... Not saying that httpd shouldn't (or won't) have an true event driven MPM, but it is hardly the manna the masses claim it to be. Depending on traffic shaping, it most certainly will be an improvement but the question is entirely about what sorts of gains, and will they be worth it for the classic module authoring community to make the sometimes painful changes necessary to support a free-threaded server. Many modules achieved worker mpm compatibility with TLS, which isn't a free-threaded solution. It was perfect for the slow internet + slower and less capable machines, but even as the bandwidth of individual clients grows, so too has the typical machine (now multi-core, very fast performance, etc). The only way to settle the debate though will be to demonstrate it :)
Re: [community] 2.3.0 alpha on October 1?
William A. Rowe, Jr. wrote:
Which brings me to the other half of [community], I'm proposing we hold
an Apache httpd {next} barcamp session for the community who are at
ApacheCon BarCamp on Tuesday to learn about what has changed, what might
change, and perhaps if we get enough folks to express interest ... about
what they want to change.
Dose anybody ever think of improving the runtime performance of Apache httpd
to be
somewhere close or at least comparable to that of Nginx? At this time Nginx
is only
a test version, but as far as I know here in China, its efficiency gain is
so tempting that
the 0.6.x and 0.7.x versions have dominated the flash-video websites, most
of which
are top traffic-ranked ones.
Lighttpd is another excellent example that provides far more better runtime
performance.
Although Apache is famous for its modular design and configuration
flexibility, it seems
these new comers are challenging the relevance of Apache in real use. Is
there any
chance for Apache to get much better performance while retaining its design
beauty?
To my knowledge, the one thread per connection network i/o model is a
suboptimal use
of the Windows IOCP (i/o completion port) mechanism. IOCP suggests that only
a very few
threads (no. of CPU cores) would be sufficient to handle tens of thousands
of requests.
Nginx uses an event driven i/o model, with economic memory allocation.
Apache does
have an event driven MPM for some platform (needs further development to
match).
Bing
School of EE CS,
Peking University,
Beijing 100871
Re: [community] 2.3.0 alpha on October 1?
William A. Rowe, Jr. wrote:
Thoughts?
I think doing *something* is good.
I'm not sure tagging 2.3.0 or having another Apache 3.0 D {ream} session
is the right thing
Right now we just need someone to write lots of code and get us started.
/imo.
Having said that, I would he happy to attend a hackathon or barcamp
session about 'new' ideas, but I would be happier to buy beer for
someone who actually took action on the ideas, and wrote some '3.0' code :-)
-Paul
Re: [community] 2.3.0 alpha on October 1?
On 08/22/2008 03:03 AM, William A. Rowe, Jr. wrote: I'm thinking of tagging 2.3.0 alpha a month before we gather in New Orleans for ApacheCon 2008/US http://us.apachecon.com/c/acus2008/ so that we can begin to gather community feedback and actually /do/ something about it at the hackathon. My gut feeling is that there are still some issues with the new authentication code. 3 Basic tests of our perl framework still fail there which might be caused by wrong tests for the trunk, but either way it should be fixed. Shouldn't this be addressed on trunk before branching (provided this is not caused by faulty tests)? Regards Rüdiger
Re: [community] 2.3.0 alpha on October 1?
Ruediger Pluem wrote: On 08/22/2008 03:03 AM, William A. Rowe, Jr. wrote: I'm thinking of tagging 2.3.0 alpha a month before we gather in New Orleans for ApacheCon 2008/US http://us.apachecon.com/c/acus2008/ so that we can begin to gather community feedback and actually /do/ something about it at the hackathon. My gut feeling is that there are still some issues with the new authentication code. 3 Basic tests of our perl framework still fail there which might be caused by wrong tests for the trunk, but either way it should be fixed. Shouldn't this be addressed on trunk before branching (provided this is not caused by faulty tests)? This is the point (1. it's alpha, 2. no branch until (2.4)|(3.0) becomes near-ready to be blessed). Let's get trunk as 2.3.0-alpha, bump trunk from 2.3.0-dev to 2.3.1-dev and start delivering these preview versions of httpd to the world, especially for module authors who want to anticipate their compatibility to httpd-next. Bill
