Flood developers, APR gurus, Cliff Wooley, Sander Striker, etc.:
Looks like I'm in the process of implementing the needed fix of
implementing multiple pool levels in Flood. The decision point is going to
be between allocating a new pool from the source pool every repeated
instance (i.e. each time
Geez... it's nice to discover everybody hasn't just dropped dead!
I see a lot of healthy 'things to do' coming out of this
thread that could inject a lot of life back into the
development... which is what the various threads the past
few days have all been about.
Action items?...
Facts to
bravo!
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, November 16, 2003 11:05 PM
Subject: Re: consider reopening 1.3
Geez... it's nice to discover everybody hasn't just dropped dead!
I see a lot of healthy
Last benchmarks I have currently are quite old.
I think the last time I ( just a USER of Apache ) did
any serious benchmarking was 2.0.40 or something...
but the results were right inline with what Rasmus
just posted.
Apache 2.0 pre-fork was a pig compared to Apache 1.3 prefork.
If I get some
Having a fallback servername of 127.0.0.1 is broken, I realise even
in IPv4 it's not a globally reachable address, but in IPv6 it's
just plain confusing and leads to a lot (well o.k. 3 ever) of reports
that Apache isnt working for someone in IPv6.
Index: server/util.c
Fantastic!
So Rasmus has just uncovered some 'other' problem then
which means (only) mod_perl is a pig on 2.0 or something?
I guess that's better than the core being the problem.
I'd like to see this get put to bed once and for all and eliminate
it from the 2.0 migration discussion(s).
Got
You are right, apache 2.0 pre fork is apache 1.3 prefork...
But one nice feature of apache 2.0 is to provide other mpm more powerfull.
worker mpm is apache 1.3.
If you look all benchmark of web server, you will see that all are now
providing threaded architectures because it's more stable and
On Mon, Nov 17, 2003 at 04:40:02AM -0500, [EMAIL PROTECTED] wrote:
Got any real numbers?
Completely unconfigured, out of the box configs;
Apache 1.3.29;
Concurrency Level: 100
Time taken for tests: 2.54841 seconds
Complete requests: 1000
Failed requests:0
Write errors:
You are right, apache 2.0 pre fork is apache 1.3 prefork...
Maybe. Maybe not. My 'FACT?:' header had a QUESTION MARK there.
Just in the last 4 or 5 messages on this thread the actual
reality has become even more obfuscated.
Rasmus seems to be saying it's a pig... but maybe he's
simply
On Sun, Nov 16, 2003 at 05:02:12PM -0800, Rasmus Lerdorf wrote:
And a threaded mpm is just not an option. Most humans
are simply not smart enough to write threadsafe code.
this is an interesting point.
I believe the moving towards threading is wrong.
I also find apache2 strongly suspective
Hi Colm...
Slainte!...
Cead mile failte romhat!
Go raibh maith agat!
Wow... I believe everything you are saying... and
please don't take this the wrong way... but I'm not
sure a test that only runs for 1.1 second and 1000
requests with 100 clients being launched ( on the
same machine? ) is a
On Mon, Nov 17, 2003 at 06:00:09AM -0500, [EMAIL PROTECTED] wrote:
Hi Colm...
Slainte!...
Cead mile failte romhat!
Go raibh maith agat!
Agus tú féin a cháirde, chaitfidh mé rá b'éidir gurb seo on
t-aon deis a bhéis gam cumarsáid le Gaeilgeoir so comh-théacs
seo, ach mar a deartaí áfach -
On Sun, 16 Nov 2003, Rasmus Lerdorf wrote:
On Sun, 16 Nov 2003, Jim Jagielski wrote:
So a useful topic is: What is *missing* in 1.3 that needs to be
addressed.
What are the features/additions that the disenfranchised 1.3 developers
want to add to 1.3...
How about support for chunked
[EMAIL PROTECTED] wrote:
--
FACT?: Apache 2.0 pre-fork ( which is the only thing still available on
some of the best platforms ) is SLOWER than Apache 1.3 pre-fork.
--
This gives someone who might be stuck with one of those pre-fork
only platforms, or anyone who just WANTS to stick with
[EMAIL PROTECTED] wrote:
Geez... it's nice to discover everybody hasn't just dropped dead!
I see a lot of healthy 'things to do' coming out of this
thread that could inject a lot of life back into the
development... which is what the various threads the past
few days have all been
Bill,
I've done some thinking about this - price/performance is only part of the
equation.
Someone needs to take a step back and see where Apache wants to *be* in two
years time. I agree with Jim that 1.x probably is just about done, it works,
people understand it and have ported their modules
On Mon, 17 Nov 2003, [ISO-8859-15] André Malo wrote:
* [EMAIL PROTECTED] wrote:
Unless anyone strenuously objects, I'm adding back the comments
regarding ScriptInterpreterSource. We're getting an increasing number of
questions about this.
I'm -0 on it, because using
To support my comments on cheap 64-bit computing see this link:
http://www.siliconvalley.com/mld/siliconvalley/7281990.htm
Sun, AMD announce plans for line of low-cost servers - 64-bit!
People will move Apache 1.x to this platform because there is virtually NO
migration cost (i.e. recoding
Any thought into parsing the results of the includes filter (offsets,
etc.). In our environment, parsing the includes files is a huge
performance hit.
We are willing to help in any way.
On Sun, 16 Nov 2003, Jeff Trawick wrote:
Too bad all these supposedly-disenfranchised people aren't around to
review 1.3
fixes. 1.3 would be healthier if they were.
And it is the reason for why they are not around that is in question here.
Why wouldn't there be plenty of hackers around
People will move Apache 1.x to this platform because there is virtually NO
migration cost (i.e. recoding modules etc) and they get a performance boost
and while replacing an aging infrastructure.
12 million user on the move - make it easy for them, buy a cheap AMD Opteron
and optimize and improve
Oh yes - forgot about v6... that's a must have for Apache. Is it available
for 1.x? If not that would be the first feature to add.
Peter
-Original Message-
From: Andre Schild [mailto:[EMAIL PROTECTED]
Sent: Monday, November 17, 2003 10:07 AM
To: [EMAIL PROTECTED]
Subject: Antw: RE:
On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote:
Oh yes - forgot about v6... that's a must have for Apache. Is it available
for 1.x? If not that would be the first feature to add.
The KAME project has IPv6 patches for 1.3.* at
ftp://ftp.kame.net/pub/kame/misc/
they
Colm MacCarthaigh wrote:
On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote:
Oh yes - forgot about v6... that's a must have for Apache. Is it available
for 1.x? If not that would be the first feature to add.
The KAME project has IPv6 patches for 1.3.* at
On Mon, 17 Nov 2003, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support)
with all the Windows
specific code stripped out and source compatability (to the extent possible) with
Apache 1.3 modules would
probably see rapid uptake. I can't
On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit
support) with all the Windows specific code stripped out and source
compatability (to the extent possible) with Apache 1.3 modules would
probably see
Glenn wrote:
On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit
support) with all the Windows specific code stripped out and source
compatability (to the extent possible) with Apache 1.3 modules would
On Nov 17, 2003, at 1:31 PM, Bill Stoddard wrote:
Colm MacCarthaigh wrote:
On Mon, Nov 17, 2003 at 11:01:46AM -0700, Peter J. Cranstone wrote:
Oh yes - forgot about v6... that's a must have for Apache. Is it
available
for 1.x? If not that would be the first feature to add.
The KAME project has
On Mon, 17 Nov 2003, Jim Jagielski wrote:
Glenn wrote:
On Mon, Nov 17, 2003 at 01:31:55PM -0500, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit
support) with all the Windows specific code stripped out and source
compatability (to
Rasmus Lerdorf wrote:
On Mon, 17 Nov 2003, Bill Stoddard wrote:
Apache 1.4, an APR'ized version of Apache 1.3 (to pick up IPV6 and 64 bit support) with all the Windows
specific code stripped out and source compatability (to the extent possible) with Apache 1.3 modules would
probably see rapid
* Brian Akins [EMAIL PROTECTED] wrote:
Any thought into parsing the results of the includes filter (offsets,
etc.). In our environment, parsing the includes files is a huge
performance hit.
Just some thoughts from top of my head:
I'd say, if we do, only with the new code. The old one is
* Colm MacCarthaigh [EMAIL PROTECTED] wrote:
unconfigured. Or make it a hard error, and have no fallback.
I'd prefer the latter. FWIW.
nd
On Mon, Nov 17, 2003 at 08:54:50PM +0100, André Malo wrote:
* Brian Akins [EMAIL PROTECTED] wrote:
Any thought into parsing the results of the includes filter (offsets,
etc.). In our environment, parsing the includes files is a huge
performance hit.
Just some thoughts from top of my
On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote:
In this economic environment (and perhaps this will turn out to be
generally true from now on), companies are not making investments in
IT unless they can get a proven and almost immediate return on that
investment. Making the jump to Apache 2.0
On Mon, 17 Nov 2003, Jim Jagielski wrote:
On Nov 17, 2003, at 2:22 PM, Bill Stoddard wrote:
In this economic environment (and perhaps this will turn out to be
generally true from now on), companies are not making investments in
IT unless they can get a proven and almost immediate return
Glenn wrote:
For files where server-side includes are used for page fragment reuse
rather than complicated server-side conditional processing, this could
be an easy win, and a bit more flexible than the XBitHack.
In our environment, we have several includes on a page, only one of
which is
* Rasmus Lerdorf [EMAIL PROTECTED] wrote:
As someone working in a company like that, I can tell you definitively
that this is not true. At least not here at the biggest web company in
the world.
*shrug*
Big or not, if it's the only one, it can develop the stuff it needs itself. I
On Nov 17, 2003, at 3:17 PM, Rasmus Lerdorf wrote:
As someone working in a company like that, I can tell you definitively
that this is not true. At least not here at the biggest web company in
the world.
-Rasmus
Well, I can certainly say that with respect to many, many of
the clients I've
Brian Akins wrote:
Any thought into parsing the results of the includes filter (offsets,
etc.). In our environment, parsing the includes files is a huge
performance hit.
We are willing to help in any way.
Hey Brian,
it has been discussed before, and the two approaches is what I recall
we
Jim Jagielski wrote:
Look at the impact of not having 2.0 modules severely
limited the acceptance of 2.0. Not having 1.4 modules
will most certainly do the same*. If 1.4 == 1.3,
binary-wise, then it's a non-issue; if not, it's
a *major* issue.
* Yes, part of the delay was due to porting, which
then *what* is the driver for 1.4 over 2.x??
Right now I think it's unknown - but with some reasoned debate I think a
path will emerge.
One other thought - Apache needs an enemy - and I mean this in the nicest
possible terms. Having been on the receiving end of the forums venom before
I know
I have the following problem: I'm trying to modify an existing apache
module to change the value of ap_deamons_limit at
run-time. I need this module receives a query through a socket or
something similar and then it modifies that parameter. The problem is
that if I do this, the web server hungs,
At 07:32 PM 11/16/2003, Martin Kraemer wrote:
...only that tomorrow's apr might not be 100% compatible with today's.
Think of mod_ssl's and mod_dav's problem (the apache_1.3 version). They
must always add the apache_1.3 version number to their own version number
to describe the API they require.
+1
My only concern is that some scarce resource might be further
dissipated by having multiple forks in progress. I had some sympathy
when 2.0 was trying to get started that 1.3 was a competitor for
attention; I don't think that's a problem any more. How audacious to
be on 1.3? Time will
On November 17, 2003 02:22 pm, Bill Stoddard wrote:
application environments. Being able to eliminate 1 machine in 3 due to
scalability improvements in 2.0 probably won't be a sufficient return
on investment for most folks. A really kick-ass load balancing/active
fail-over feature in mod_proxy
On Mon, Nov 17, 2003 at 08:56:28PM +0100, André Malo wrote:
* Colm MacCarthaigh [EMAIL PROTECTED] wrote:
unconfigured. Or make it a hard error, and have no fallback.
I'd prefer the latter. FWIW.
Same here. It probably breaks a lot of lame configs though, all the
same ... patch attached.
Mark's good list got me thinking that we are coming at this in one of
the classic ways.Enumerate some issues, look for some solutions.
I'd like to suggest that there is another way. We should be looking
for the fun opportunities.
Installed bases are very hard to move forward. You need to
Ben Hyde wrote:
Success stories that create a sense of
safety.
I know of some folks that use an Apache 2 derivitive (a -very- close derivitive) with the worker MPM to
support nearly 10, concurrent clients with a -single- child process. Big honking complex third party
module figures
Ben Hyde wrote:
In this discussion people have been making two kinds of lists. The
list of hypothetical reasons why activity seems to be petering out.
The list of possible cures for those hypothetical ills.
We need a third list. A list of fun hacks that 2.0 enables.
It would be good to
On Mon, Nov 17, 2003 at 05:17:20PM -0500, Ben Hyde wrote:
:
: I'd like to suggest that there is another way. We should be looking
: for the fun opportunities.
Fun stuff is fun. But I'm looking for features that can be classified
as useful. For example, getting a FreeBSD 5.x / Apache 2.x /
I need to implement a control module that creates a child process to
receive request to modify a global variable of Apache, if it creates a
child that has a copy of this variable, the other process doesn't view
the change. Can i insert this global variable into scoreboard structure
and int this
On Sun, 2003-11-16 at 17:37, Aaron Bannert wrote:
On Sat, Nov 15, 2003 at 05:20:33PM -0800, Sander Striker wrote:
On Sun, 2003-11-16 at 15:36, Aaron Bannert wrote:
I've made some tarballs of the httpd-2.1 tree. I just pulled HEAD of
both httpd and apr (as of about an hour ago, just before
On Sun, 2003-11-16 at 01:12, Glenn wrote:
Ok, so Apache2 uptake is slower than desired for some (not all) on this
list. That's only logical given the success and therefore inertia to stay
with Apache 1.3. But there are more than a few other factors mentioned in
recent threads that are
On Tue, Nov 18, 2003 at 01:29:50AM +0100, David Herrero wrote:
I need to implement a control module that creates a child process to
receive request to modify a global variable of Apache, if it creates a
child that has a copy of this variable, the other process doesn't view
the change. Can i
54 matches
Mail list logo
