Brian Akins wrote:
Bill Stoddard wrote:
If the event MPM is working properly, then a worker thread should not
be blocking waiting for the next ka
request. You still have the overhead of the tcp connection and some
storage used by httpd to manage connection
events but both of those are small c
-1 on Win32, caddr_t isn't sufficiently portable (fix committed).
Also, LDAP TLS is altogether broken, my gut says disable it, but
this may not be an issue in the previous flavor of apr-util.
I'm testing HEAD - which is why my apr-util result might vary.
And stumbled across an old install of apach
Glenn Gallien <[EMAIL PROTECTED]> writes:
> I'm having the same problem while installing libapreq2-2.0.5-dev on
> FreeBSD 5.4. Error: /usr/bin/ld: cannot find -lexpat
>
> Apache 2 and mod_perl are installed from souce. Libtool, autoconf and
> automake where installed from ports. I've tried creat
+1 netware
>>> [EMAIL PROTECTED] Friday, June 17, 2005 1:40:50 AM >>>
Please test and vote on releasing 2.1.5 as -alpha.
Available at:
http://httpd.apache.org/dev/dist/
(might take up to 2 hours for the files to appear, due to the rsync delay)
MD5 (httpd-2.1.5-alpha.tar.Z) = f9dea893723fe7ddb8
fredag 17 juni 2005 09.40 skrev Paul Querna:
> Please test and vote on releasing 2.1.5 as -alpha.
>
> Available at:
> http://httpd.apache.org/dev/dist/
>
> (might take up to 2 hours for the files to appear, due to the rsync delay)
>
> MD5 (httpd-2.1.5-alpha.tar.Z) = f9dea893723fe7ddb8e9c5a4225a276b
Any interest/objections to added another MPM query>
AP_MPMQ_IDLE_WORKERS
(or some other name)
in worker.c, could just add this to ap_mpm_query:
case AP_MPMQ_IDLE_WORKERS:
*result = ap_idle_thread_count;
return APR_SUCCESS;
and in perform_idle_server_maintenance we w
At 10:34 AM 6/17/2005, luca regini wrote:
>The problem shows itself with the following simple module.
>When the hook is of type "ap_hook_post_read_request" per dir configuration is
>not instantiated
Not a bug; nobody has started to break down the incoming
request yet to figure out any locat
At 10:42 AM 6/17/2005, William A. Rowe, Jr. wrote:
Checkout date/time is generally the right choice for developers,
because otherwise make doesn't always pick up when a file has
changed. (I've been bit by the Visual SourceSafe "modification
time" default enough times.)
Although - heh - you a
Jim Gallacher wrote:
It just occured to me that the performance problem may be related to
opening and closing the dbm file for every record insertion. Adjusting
the test so that the file is only opened once, I get O(1), and a great
speed boost: 0.2 seconds / per 1000 records all the way up to 5
Brian Akins wrote:
Bill Stoddard wrote:
If the event MPM is working properly, then a worker thread should not
be blocking waiting for the next ka
request. You still have the overhead of the tcp connection and some
storage used by httpd to manage connection
events but both of those are small c
* luca regini wrote:
> The problem shows itself with the following simple module.
> When the hook is of type "ap_hook_post_read_request" per dir
> configuration is not instantiated
> correctly and debug has always value -1. With other kinds of hooks the
> debug variable is correctly is instantiate
The problem shows itself with the following simple module.When the hook is of type "ap_hook_post_read_request" per dir configuration is not instantiated correctly and debug has always value -1. With other kinds of hooks the debug variable is correctly is instantiated with the various values
At 10:12 AM 6/17/2005, Brian Akins wrote:
>>Adding an indexed list of 'counts' would be
>>very lightweight, and one atomic increment and decrement per state
>>change. This would probably be more efficient than walking the
>>entire list.
>
>Sounds good. Of course, when changing from on state to an
Jorge, I've got lots of feedback and a few mea culpas below...
At 09:46 AM 6/17/2005, Jorge Schrauwen wrote:
>Reply seemd to be missing :(
>So i'll post again.
>
>First i updated awk.exe, i seem to have had the same one as online, i
>updated anyway to be sure.
>
>This time i wanted to do a full bu
. Snipping all the other issues, which are largely valid and do
contain some good ideas
Akins, Brian wrote:
Here's the problem:
If you want to use keepalives, all of you workers
(threads/procs/whatever)
can become busy just waiting on another request on a keepalive
connection.
Rais
Nicolas Lehuen wrote:
Anyway, implementing
FS2 instead of FS is not that difficult, and if it yields predictable
results even on ext3, then we should go for it.
Already done - it's just a couple of extra lines. Doing some testing today.
Are you replacing FS with FS2 or adding a new implemen
2005/6/17, Jim Gallacher <[EMAIL PROTECTED]>:
> Nicolas Lehuen wrote:
> > Hi Jim,
> >
> > You've done a pretty impressive work here. What surprises me is the
> > O(n) behaviour on DBM and FS. This seems to mean that indexes (or
> > indices, if you prefer) ar not used.
>
> ext2/ext3 uses a linked l
At 11:25 AM 6/16/2005, Greg Marr wrote:
>At 12:01 PM 6/16/2005, William A. Rowe, Jr. wrote:
>>Back to httpd land; the question is --- is this the right choice for *our
>>tarballs*? Which may or may not be related to the question above. In any
>>case; this is useful metadata even for end users w
William A. Rowe, Jr. wrote:
Yes it makes sense. But I'd encourage you to consider dropping that
keepalive time and see if the problem isn't significantly mitigated.
It is mitigated somewhat, but we still hit maxclients without our "hack"
in place.
Right now, it does take cycles to walk th
Bill Stoddard wrote:
If the event MPM is working properly, then a worker thread should not be
blocking waiting for the next ka
request. You still have the overhead of the tcp connection and some
storage used by httpd to manage connection
events but both of those are small compared to a blocking
Reply seemd to be missing :(
So i'll post again.
First i updated awk.exe, i seem to have had the same one as online, i
updated anyway to be sure.
This time i wanted to do a full build with zlib and ssl.
First Problem:
SSL build commands as described in the documenation didn't work.
These command
At 09:27 AM 6/17/2005, Brian Akins wrote:
>>Also, I'd be very concerned
>>about additional load - clients who are retrieving many gifs (with
>>no pause at all) in a pipelined fashion will end up hurting the
>>over resource usage if you force them back to HTTP/1.0 behavior.
>
>Yes, but if all thread
Nick Kew wrote:
Could that be done dynamically? As in, make the max keepalive time a
function of how near the server is to running out of spare workers?
Sure. I'd have to poke around a bit to see the best way to do it.
Speed is of utmost concern for us. I guess I could dynamically change
r-
Akins, Brian wrote:
Here's the problem:
If you want to use keepalives, all of you workers (threads/procs/whatever)
can become busy just waiting on another request on a keepalive connection.
Raising MaxClients does not help.
The Event MPM does not seems to really help this situation. It seems t
Akins, Brian wrote:
> Short Term solution:
>
> This is what we did. We use worker MPM. We wrote a simple modules that
> keep track of how many keeapalive connections are active. When a threshold
> is reached, it does not allow anymore keepalives. (Basically sets
> r->connection->keepalive = A
William A. Rowe, Jr. wrote:
No, it doesn't :) But lowering the keepalive threshold to three
to five seconds does.
For us, in heavy loads, that's 3-5 seconds that a thread cannot process
a new client. Under normal circumstances, the 15 seconds is fine, but
when we are stressed, we need to
At 08:11 AM 6/17/2005, Akins, Brian wrote:
>If you want to use keepalives, all of you workers (threads/procs/whatever)
>can become busy just waiting on another request on a keepalive connection.
>Raising MaxClients does not help.
No, it doesn't :) But lowering the keepalive threshold to three
Title: Keepalives
Here's the problem:
If you want to use keepalives, all of you workers (threads/procs/whatever)
can become busy just waiting on another request on a keepalive connection.
Raising MaxClients does not help.
The Event MPM does not seems to really help this situation. It seem
Hi,
On my old Suse (7.2 (i386)) httpd (2.1 head) is not running and in the error_log
I have the following:
+++
[Fri Jun 17 13:58:50 2005] [error] (88)Socket operation on non-socket:
apr_socket_accept: (client socket 0)
+++
This only appends when starting http via crontab.
Does it make sense
Paul Querna wrote:
Please test and vote on releasing 2.1.5 as -alpha.
+1 from me, Tested on FreeBSD 6.0-CURRENT and NetBSD 2.0.
-Paul
Please test and vote on releasing 2.1.5 as -alpha.
Available at:
http://httpd.apache.org/dev/dist/
(might take up to 2 hours for the files to appear, due to the rsync delay)
MD5 (httpd-2.1.5-alpha.tar.Z) = f9dea893723fe7ddb8e9c5a4225a276b
MD5 (httpd-2.1.5-alpha.tar.bz2) = 8ec926f27c2768c7cbd24f
31 matches
Mail list logo