Mailing List Archive: Apache: Dev

[community] 2.3.0 alpha on October 1?

1 2

View All

Index | Next | Previous | View Threaded

wrowe at rowe-clan

Aug 21, 2008, 6:03 PM

Post #1 of 29 (760 views)
Permalink

[community] 2.3.0 alpha on October 1?

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.

Ok, I'm using 'we' sort of liberally, I'm training a day of httpd all day
Mon, and Rich takes the stage Tuesday which happens to be BarCamp day moreso
than hackathon. Since it doesn't look likely for me to do so much hacking,
the least I can do is offer to RM the first alpha.

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. Think in terms of Rich's "What I hate about
Apache", x 15 voices or so :)

Thoughts?

chip at force-elite

Aug 22, 2008, 11:57 AM

Post #2 of 29 (741 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

Brian.Akins at turner

Aug 22, 2008, 12:04 PM

Post #3 of 29 (740 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

On 8/22/08 2:57 PM, "Paul Querna" <chip[at]force-elite.com> wrote:
> 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 :-)

Is there a beer/line-of-code standard? ;)

If we really want "D" to be as generic as we say, then we really need to rip
all of the http stuff out of core. Easier said than done, I know.

Did we go anywhere with the serf buckets investigation? I'm still very
interested in that and the whole "async vs threads discussion."

Wish Apachecon hadn't been scheduled the week of US presidential elections.
My busiest time every 4 years. I used to live in NOLA, so I know there are
plenty of places for Paul to buy me beer...

--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies

rpluem at apache

Aug 22, 2008, 3:23 PM

Post #4 of 29 (735 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

wrowe at rowe-clan

Aug 22, 2008, 4:24 PM

Post #5 of 29 (734 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

bswen at pku

Aug 31, 2008, 6:49 AM

Post #6 of 29 (667 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

wrowe at rowe-clan

Sep 1, 2008, 12:28 AM

Post #7 of 29 (659 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

jim at jaguNET

Sep 1, 2008, 5:11 AM

Post #8 of 29 (656 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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.

wrowe at rowe-clan

Sep 1, 2008, 12:48 PM

Post #9 of 29 (645 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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 :)

Brian.Akins at turner

Sep 2, 2008, 8:31 AM

Post #10 of 29 (637 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

On 9/1/08 8:11 AM, "Jim Jagielski" <jim[at]jaguNET.com> 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

bswen at pku

Sep 2, 2008, 10:02 AM

Post #11 of 29 (635 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

bill at wstoddard

Sep 2, 2008, 10:47 AM

Post #12 of 29 (636 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

Akins, Brian wrote:
> On 9/1/08 8:11 AM, "Jim Jagielski" <jim[at]jaguNET.com> 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

Brian.Akins at turner

Sep 2, 2008, 11:07 AM

Post #13 of 29 (635 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

On 9/2/08 1:02 PM, "bing swen" <bswen[at]pku.edu.cn> 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

bswen at pku

Sep 2, 2008, 12:15 PM

Post #14 of 29 (636 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

wrowe at rowe-clan

Sep 2, 2008, 3:47 PM

Post #15 of 29 (623 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

Brian.Akins at turner

Sep 2, 2008, 4:54 PM

Post #16 of 29 (624 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

On 9/2/08 3:15 PM, "bing swen" <bswen[at]pku.edu.cn> 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

bill at wstoddard

Sep 3, 2008, 9:19 AM

Post #17 of 29 (606 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

bill at wstoddard

Sep 3, 2008, 9:24 AM

Post #18 of 29 (606 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

Akins, Brian wrote:
> On 9/2/08 3:15 PM, "bing swen" <bswen[at]pku.edu.cn> 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

wrowe at rowe-clan

Sep 3, 2008, 9:56 AM

Post #19 of 29 (605 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

bill stoddard wrote:
>
>> * 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?

I'm suggesting... we already allow them to toggle it, but now have a
portable directive for toggling accept behavior on all platforms. With
the AcceptFilter idea, we may as well take it one step further and allow
'data' mode just as linux/solaris do (no accept until a packet is received.)

Adding the first packet in the AcceptEx should be an improvement.

Oh, Windows 2008 allows connection reuse without TransmitFile :)

iamstever at gmail

Sep 3, 2008, 11:54 PM

Post #20 of 29 (578 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

> 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?)

bswen at pku

Sep 4, 2008, 1:22 AM

Post #21 of 29 (577 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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
bswen[at]pku.edu.cn

Brian.Akins at turner

Sep 4, 2008, 6:41 AM

Post #22 of 29 (572 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

On 9/4/08 4:22 AM, "Bing Swen" <bswen[at]pku.edu.cn> 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

Brian.Akins at turner

Sep 4, 2008, 6:50 AM

Post #23 of 29 (572 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

On 9/4/08 2:54 AM, "steve" <iamstever[at]gmail.com> 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

iamstever at gmail

Sep 10, 2008, 10:39 PM

Post #24 of 29 (416 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

>> (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.

bswen at pku

Sep 14, 2008, 1:09 AM

Post #25 of 29 (339 views)
Permalink

Re: [community] 2.3.0 alpha on October 1? [In reply to]

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

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com