On Fri, 17 Jun 2005, Nicolas Lehuen wrote:
As for the MySQL implementation
I'd stay away from anything vendor-specific in mod_python, because then
the question becomes why not a postresql, why not oracle, etc.
Grisha
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
I was thinking we'd still use the current global locking scheme, but
keep the file open between requests. Not sure if this would be robust
or just asking for dbm file corruption though.
I'm pretty sure it won't
Gregory (Grisha) Trubetskoy wrote:
On Fri, 17 Jun 2005, Jim Gallacher wrote:
Any objection to just a SqlSession base class?
May be - it depends on how complex it becomes. Any attempts I've to
generalize SQL/DB stuff tend to become a mess since there are no firm
standards in this area,
The uploaded file
Apache-Test-1.25.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GO/GOZER/Apache-Test-1.25.tar.gz
size: 145772 bytes
md5: 315998641c7ba5d3a315da96c10e64d1
Changes since 1.24:
provide $Apache::TestUtil::DEBUG_OUTPUT as target for t_debug()
statements,
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) =
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
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
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
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
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
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 =
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
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
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 threads are
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
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
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 the
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 who
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 list to access
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
. 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.
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 build
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 another you
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 found in
* 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 instantiated with
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
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
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
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 location.
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
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
MD5
+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) =
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 creating
-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
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
35 matches
Mail list logo
