ld perform when the back ends are only
lightly or moderately loaded and the front end queue is usually empty.
Greg Ames
#x27;all have already
decided on the latter. If not, it is trivial to make event behave like
worker, controlled by a config directive if you feel that's necessary. I
believe the code is in ap_process_async_connection. I *really* regret not
doing that in the first event patch I posted to this list. Que sera, sera.
Enough ranting.
Greg Ames
see PR 49504 https://issues.apache.org/bugzilla/show_bug.cgi?id=49504 for
an excellent analysis with supporting traces. There have been various
other PRs that haven't led to resolution, perhaps because it is easy to
circumvent via AcceptMutex sysvsem and is highly timing dependent.
The problem af
On Wed, Jan 25, 2012 at 8:00 AM, Jeff Trawick wrote:
> I'll start with the patch for CVE-2011-4317.
The 2.2.x patch for CVE-2011-3607 (r1227280) applies and builds fine
on 2.0.x. Vote in STATUS?
Greg
On Tue, Dec 20, 2011 at 4:26 AM, William A. Rowe Jr.
wrote:
> We should come to a conclusion on this.
How about this for 2.2.x ?
--- server/util.c (revision 1179624)
+++ server/util.c (working copy)
@@ -82,6 +82,8 @@
#define IS_SLASH(s) (s == '/')
#endif
+/* same as APR_SIZE_MAX w
On Thu, Dec 1, 2011 at 2:52 PM, Yuri Arabadji wrote:
>
>
> We've got mpm worker with the following config:
>
> http://stage.fused.net/huy#worker.c
>
> MaxSpareThreads 250
> MinSpareThreads 25
> ThreadsPerChild 25
> ServerLimit 30
> MaxClients 750
>
> It's pretty obvious the total number of child
On Tue, Nov 22, 2011 at 9:15 AM, Jeff Trawick wrote:
>
> > So I have to ask: is the intent to really release 2.4.0 anytime soon,
> > or are is it a simple sandbox for people to play around in?
>
> It is safe to predict how that question would be answered ;)
>
> Alternately, "Let's plan for a RC t
On Fri, Nov 18, 2011 at 4:38 PM, Jeff Trawick wrote:
>
> > but my fears about the performance of the design seem to be confirmed.
> my
> > fastest run so far with trunk + this patch,
> >
> > Requests per second:7749.66 [#/sec] (mean)
>
> backing up to the prior state (with the mutex), it woul
On Fri, Nov 18, 2011 at 3:48 PM, Jeff Trawick wrote:
>
> Try this:
>
> Index: server/mpm/event/event.c
> ===
> --- server/mpm/event/event.c(revision 1203816)
> +++ server/mpm/event/event.c(working copy)
> @@ -1483,9 +1483,9 @
On Tue, Nov 15, 2011 at 10:51 AM, wrote:
>
> Log:
> Create a new lock free circular queue, and use it in the EventMPM to
> remove the timeout mutex that was wrapping both timeout queue operations
> and pollset operations.
>
> @@ -1632,6 +1672,20 @@ static void * APR_THREAD_FUNC listener_t
>
On Mon, Nov 14, 2011 at 11:12 AM, Paul Querna wrote:
>
> The problem became that in trunk, we had to told the lock for the
> timeout queues while we were doing the pollset operation. The
> pollset already had its own internal mutex too, for its own rings. So
> we were double locking a piece of
On Fri, Nov 11, 2011 at 11:07 PM, Paul Querna wrote:
>
> 4) Have the single Event thread de-queue operations from all the worker
> threads.
>
Since the operations include Add and Remove, are you saying we would have
to have to wait for a context switch to the listener thread before
apr_pollset_a
On Thu, Nov 10, 2011 at 4:12 PM, Stefan Fritsch wrote:
> Hi,
>
> I intend to set MaxMemFree by default.
>
>
+1.
What about a way to view allocator memory use? per child totals in
mod_status would be most excellent.
Greg
On Thu, Nov 3, 2011 at 4:09 PM, Jeff Trawick wrote:
> On Thu, Nov 3, 2011 at 3:38 PM, Greg Ames wrote:
> > On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
> >>
> >> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
> >> >
>
> > I worked on
On Thu, Nov 3, 2011 at 1:06 PM, Jim Jagielski wrote:
>
> On Nov 3, 2011, at 8:11 AM, Jeff Trawick wrote:
> >
> > Maybe I misunderstood, but I thought Rüdiger's original point was on
> > track: EAGAIN here is a bug to fix somewhere since EAGAIN from
> > blocking read is should-not-occur, and this
On Fri, Oct 14, 2011 at 2:34 PM, Stefan Fritsch wrote:
>
> > In pre-2.4, it seems we could be more tolerant than 10 subs or 8K
> > if we're going to be returning a NULL that's never been returned
> > in practice.
>
> Introducing an arbitrary length limit seems pretty invasive for 2.2.x.
>
>
> Btw
On Fri, Oct 14, 2011 at 4:44 AM, Nick Kew wrote:
>
> If we include it in 2.4 then we're making libxml2 a dependency.
> That's of concern primarily to packagers,
I doubt that I could find libxml2 for z/OS. I vote for keeping it a
separate module.
> but it's a decision
> we should at least tak
On Tue, Aug 30, 2011 at 1:54 PM, Jim Jagielski wrote:
> Could I get at least 1 more binding vote…??
>
>
yep. +1
Greg
On Tue, Aug 30, 2011 at 12:48 PM, William A. Rowe Jr.
wrote:
> On 8/30/2011 10:18 AM, Jim Jagielski wrote:
> > If we get enough votes by, say, 1:30pm Eastern time (2hrs), I'll retag
> > and reroll… Otherwise, I'll go ahead w/ releasing 2.2.20.
> >
> > PS: Power and net are bouncing like jumping be
On Mon, Aug 29, 2011 at 4:38 PM, William A. Rowe Jr. wrote:
> On 8/29/2011 10:40 AM, j...@apache.org wrote:
> > Author: jim
> > Date: Mon Aug 29 15:40:19 2011
> > New Revision: 1162874
> >
> > Changes with Apache 2.2.20
> >
> > + *) SECURITY: CVE-2011-3192 (cve.mitre.org)
> > + core: Fix han
On Mon, Aug 29, 2011 at 12:40 PM, "Plüm, Rüdiger, VF-Group" <
ruediger.pl...@vodafone.com> wrote:
> I am fine with this on 2.2.x. +1.
>
+1 here too
On Sun, Aug 28, 2011 at 4:22 PM, Stefan Fritsch wrote:
looks good overall.
+while (start64 - off_first > (apr_uint64_t)copy->length) {
+apr_bucket *tmp;
+int i = 0;
+if (i++ >= 9)
+
On Sat, Aug 27, 2011 at 4:44 PM, Eric Covener wrote:
>
> [ x ] just the cheap brigade copy + sum_len > clen failsafe
>
and I like the idea of having a runtime switch to turn off merging in
trunk. it could take care of client breakage as well as making it easy to
keep 2.2 in sync.
Greg
On Fri, Aug 26, 2011 at 10:27 AM, Jim Jagielski wrote:
> >
> > I guess we can do both: Count the ',' and give the number to
> apr_array_make
> >
>
> Doesn't that mean that someone can craft a nasty Range (e.g: 0-0,1-1,2-2,
> 3-3,….- and cause us to preallocate a bunch
> of memory
the wrong order,
> so e.g.
>
> 2000-3000,1000-2000
>
> or
>
> 2000-3000,1500-2500
>
> But I think this check is currently wrong as you point out. Currently not
> sure how to fix it.
>
> Regards
>
> Rüdiger
>
> --
> *From:*
On Thu, Aug 25, 2011 at 7:02 PM, wrote:
>
> +if (!(ranges[i].start > ranges[i-1].end + 1 &&
> + ranges[i].end < ranges[i-1].start - 1))
>
> and the if condition looks similar. the first test is fine, but why is
ranges[i].end < ranges[i-1].start a good thing? sin
On Thu, Aug 25, 2011 at 7:02 PM, wrote:
>
> Log:
> Put parsed ranges into an array and perform merges on that array.
>
> +if (i > 0) {
> +if (!(ranges[i].start > ranges[i-1].end + 1 &&
> + ranges[i].end < ranges[i-1].start - 1))
> +{
> +
On Thu, Aug 25, 2011 at 5:43 PM, wrote:
>
> avoid inserting the same bucket into bbout twice, causing an endless loop
>
> --- httpd/httpd/trunk/modules/http/byterange_filter.c (original)
> +++ httpd/httpd/trunk/modules/http/byterange_filter.c Thu Aug 25 21:43:32
> 2011
> @@ -195,8 +195,8 @@ stati
On Thu, Aug 25, 2011 at 10:25 AM, Jim Jagielski wrote:
> Now that the memory utilz is being fixed, we need to determine
> what sort of usage we want to allow… I'm guessing that people
> are ok with http://trac.tools.ietf.org/wg/httpbis/trac/ticket/311
> as the guiding spec?
I'm no longer convin
On Wed, Aug 24, 2011 at 5:16 PM, Stefan Fritsch wrote:
>
> I have another idea: Instead of using apr_brigade_partition write a
> new function ap_brigade_copy_part that leaves the original brigade
> untouched. It would copy the necessary buckets to a new brigade and
> then split the first and last
On Wed, Aug 24, 2011 at 5:06 PM, Jim Jagielski wrote:
> I'm cool w/ that… treat non-ascending ranges as potential hinky
> and count those and only allow a certain number of them…
>
> Still not sure if we should count overlaps as bad or not…
> that RFC example troubles me:
>
> 14.35.1 Byte Ranges
On Wed, Aug 24, 2011 at 3:19 PM, Jim Jagielski wrote:
>
> >
> > If we only merge adjacent ascending ranges, then it seems like an
> attacker could just craft a header where the ranges jump around and dodge
> our fix.
> >
>
> I think no matter what, we should still have some sort of
> upper limit
On Wed, Aug 24, 2011 at 12:42 PM, Jim Jagielski wrote:
>
> On Aug 24, 2011, at 12:22 PM, William A. Rowe Jr. wrote:
>
> >
> > 0-, 40-50 becomes 0-
>
> > 0-499, 400-599 becomes 0-599
>
> > 1000-1075, 200-250, 1051-1100 becomes 1000-1100, 200-250
>
> This goes against Roy's recommendation to 416
On Wed, Aug 24, 2011 at 10:33 AM, "Plüm, Rüdiger, VF-Group" <
ruediger.pl...@vodafone.com> wrote:
> **
>
>
> I think mod_deflate is just the tool to convert an O(N^2) data size problem
> into an O(N^2) CPU usage problem, where N is some function of
> LimitRequestLine. If the file size is smaller
On Wed, Aug 24, 2011 at 10:56 AM, Dirk-Willem van Gulik <
di...@webweaving.org> wrote:
+1 with Eric's edits. specifically,
>
> 1) Use mod_rewrite to limit the number of ranges:
>
Option 1 doesn't use mod_rewrite.
Option 1:
> # drop Range header when more than 5 ranges.
> # C
On Wed, Aug 24, 2011 at 9:01 AM, "Plüm, Rüdiger, VF-Group" <
ruediger.pl...@vodafone.com> wrote:
>
> > Hmm - when I remove mod_deflate (i.e. explicitly as it is the
> > default in all our installs) and test on a / entry which is a
> > static file which is large (100k)* - then I cannot get apache
>
On Tue, Aug 23, 2011 at 3:32 PM, William A. Rowe Jr. wrote:
>
> I suggest we should be parsing and reassembling the list before we
> start the bucket logic.
>
> I propose we satisfy range requests in the only sensible manner, returning
> the ranges in sequence,
>
yeah, overlapping ranges should
I don't remember any discussions on the subject or reasons why the timing is
as late as it is. I assume signal handlers are cloned by the fork(). ++1 to
eliminating silent failures.
Greg
On Sun, Jul 24, 2011 at 2:25 PM, Stefan Fritsch wrote:
> Hi,
>
> the Unix MPMs detach from the console in t
On Sun, Jun 19, 2011 at 8:49 AM, Stefan Fritsch wrote:
>
>
> Speaking about config options, I think that MaxClients should be
> renamed to MaxWorkers, because it limits the number of worker threads,
> not the number of clients. As with the MaxRequestsPerChild ->
> MaxConnectionsPerChild rename, we
hey I like the concept a lot! a quick peek at
http://apache.org/server-status shows 15 Cs for threads tied up in lingering
close, something like 50 Keepalive threads, and only 13 threads actually
reading or writing.
On Mon, Apr 25, 2011 at 8:53 PM, Jeff Trawick wrote:
> has anyone played with t
On Tue, Oct 12, 2010 at 5:22 PM, Jeff Trawick wrote:
>
> Someone mentioned using 2.2 event in production on the list,today or
> yesterday, so I peeked at 2.2 and this bug appears to affect it. Any
> interest out there in seeing what it takes to backport?
>
yes, I'd like to see it fixed on 2.2.
On Thu, Apr 29, 2010 at 12:06 PM, Greg Ames wrote:
>
> The last time I checked, trunk had a related bug:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43359 .
>
> . I will look at the patch again and forget mod_status bells and whistles
> for now.
OK, I reviewed thi
I re-read this thread and see that we have a request in progress, so this
isn't RFC approved behavior. Sorry for the noise.
Greg
On Sun, Apr 25, 2010 at 2:07 PM, Rainer Jung wrote:
> On 23.03.2010 15:30, Jeff Trawick wrote:
>
>>
> Is that expected behaviour? It doesn't seem reproducible for
In 2.2, it is expected behavior. The RFC allows the server to close
keepalive connections when it wants.
The last time I checked, trunk had a related bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43359 . Connections
waiting for network writes can also be handled as poll events. But Eve
On Tue, Sep 15, 2009 at 8:07 AM, Jeff Trawick wrote:
> On Mon, Sep 14, 2009 at 4:27 PM, Greg Ames wrote:
>
>> I'm trying to debug a problem where apparently the accept mutex went bad
>> on a z/OS system running the worker MPM. I'm guessing that some memory that
>
I'm trying to debug a problem where apparently the accept mutex went bad on
a z/OS system running the worker MPM. I'm guessing that some memory that we
use for the semaphore got clobbered but don't have proof yet. The error log
looks like:
[Mon Sep 07 08:01:59 2009] [emerg] (121)EDC5121I Invalid
On Tue, Jul 14, 2009 at 11:47 AM, "Plüm, Rüdiger, VF-Group" <
ruediger.pl...@vodafone.com> wrote:
>
> All very true. But how about the following patch. It should do no
> harm and should solve the issue in at least some cases (I think
> in most cases):
>
> Index: modules/filters/mod_deflate.c
>
> +
+1
Greg
On Fri, Oct 10, 2008 at 10:36 AM, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> Based on the positive feedback on the test tarballs, I'd
> like to start a vote on releasing 2.2.10. I'm looking to
> release on Tuesday, since I'll be traveling Monday, so I'll
> close the vote on Tues AM.
>
On Fri, Oct 10, 2008 at 10:31 AM, Greg Ames <[EMAIL PROTECTED]> wrote:
>
> I will take a look at the APR atomics and see if the operations that
> Event's fdqueue is using are less supported than the atomics used in
> worker.
>
No difference in support on ia32 + gcc;
On Thu, Oct 9, 2008 at 5:29 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> Does anybody see problems with this or are we still too worried about
> the correct handling of signed vs. unsigned variables by apr_atomic_
> to use this in a non experimental MPM?
signed vs unsigned doesn't bother
On Tue, Oct 7, 2008 at 2:37 PM, Jim Jagielski <[EMAIL PROTECTED]> wrote:
> ... at the usual location:
>
>http://httpd.apache.org/dev/dist/
>
> The availability of these test tarballs does not constitute
> an official release, however please download and test
> as a VOTE will be called for
On Tue, Oct 7, 2008 at 7:03 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> I am currently looking at PR45605 (
> https://issues.apache.org/bugzilla/show_bug.cgi?id=45605)
> and the analysis and the resulting patch in Comment 4 look good to me
> (https://issues.apache.org/bugzilla/show_bug.cgi?id=
On Tue, Oct 7, 2008 at 7:03 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
> One comment in the event version of ap_queue_info_wait_for_idler confuses
> me:
>
> * A negative value in queue_info->idlers tells how many
> * threads are waiting on an idle worker.
>
> IMHO this would require ap_qu
On Tue, Oct 7, 2008 at 5:11 AM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> >The
> > problem is that they all stay ESTABLISHED for KeepAliveTimeout seconds.
> I
> > was expecting to see 2 of them drop after 30 seconds. Any suggestions?
>
> You need one more request after 30 seconds to trigge
On Mon, Oct 6, 2008 at 4:34 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
> Thanks for reviewing. First of all I guess you should increase the
> KeepAliveTimeout
> to a large value like 5 minutes to make observations easier. Furthermore I
> would increase
> the ttl parameter of your BalancerMemb
On Mon, Oct 6, 2008 at 3:13 PM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>
> On 10/06/2008 04:42 PM, Jim Jagielski wrote:
> > Subj says it all...
>
> Thanks for doing RM Jim. So c'mon guys. There must be someone
> out there that reviews the remaining patch that misses only
> *one* vote.
>
what
On Sun, Sep 7, 2008 at 8:57 AM, Arnab Ganguly <[EMAIL PROTECTED]> wrote:
> Hi All,
> How do I enable lingering_close in Apache.Is it enabled by default in
> Apache 2.2.8 ?
>
yes.
> Is there anyway to check it.
>
Trace the system calls. On Linux, you can run strace against one of the
worker pr
On Sat, Sep 6, 2008 at 4:38 AM, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
>
>> +bb = apr_brigade_create(r->pool, c->bucket_alloc);
>>
>
> This is bad. Please store the brigade in the filter context and reuse it,
> by cleaning it. See also
> http://httpd.apache.org/docs/trunk/en/developer/outpu
:46:53 PM
Subject: Re: one word syncronize once more
Greg Ames wrote:
> please see rev. 558039. requests_this_child does not need to be 100%
> accurate. the cure below is worse than the disease.
>
> Greg
>
> -requests_this_child--; /* FIXME: should be synchro
please see rev. 558039. requests_this_child does not need to be 100% accurate.
the cure below is worse than the disease.
Greg
- Original Message
From: Dmytro Fedonin <[EMAIL PROTECTED]>
To: dev@httpd.apache.org
Sent: Thursday, June 14, 2007 11:49:42 AM
Subject: one word syncronize onc
:00:34 PM
Subject: Re: svn commit: r554011 -
/httpd/httpd/trunk/modules/filters/mod_deflate.c
On 07/10/2007 09:27 PM, Greg Ames wrote:
> no objections in principle to your suggested changes. but in practice, I
> don't see where an error bucket gets flagged as metadata. seems like
no objections in principle to your suggested changes. but in practice, I don't
see where an error bucket gets flagged as metadata. seems like they should be.
Greg
- Original Message
From: Ruediger Pluem <[EMAIL PROTECTED]>
To: dev@httpd.apache.org
Sent: Saturday, July 7, 2007 4:13:08 P
--- Ruediger Pluem <[EMAIL PROTECTED]> wrote:
> >>check_pipeline: use AP_MODE_SPECULATIVE to check for data in the input
> filters
> >>to accomodate mod_ssl's input filter. AP_MODE_EATCRLF is essentially a
> no-op
> >>in that filter.
> >
> > EATCRLF was used here for a specific reason though -
> > check_pipeline: use AP_MODE_SPECULATIVE to check for data in the input
> filters
> > to accomodate mod_ssl's input filter. AP_MODE_EATCRLF is essentially a
> no-op
> > in that filter.
>
> EATCRLF was used here for a specific reason though - the fact that "many
> browsers" (says ap_core_inp
--- Henri Gomez <[EMAIL PROTECTED]> wrote:
> Hi to all,
>
> I'm trying to adapt mod_jk to i5/OS v5r4 and see the following in
> mod_jk.log (debug mode)
>
> [Tue Apr 17 16:23:44 2007] [6589:0038] [debug] jk_uri_worker_map.c
> (423): rule map size is 0
> [Tue Apr 17 16:23:44 2007] [6589:0038] [er
--- steve <[EMAIL PROTECTED]> wrote:
> > I use it too, and have meddled with it enough at a source level to feel
> > comfortable running it. It has obvious, documented, problems (don't use
> > it with mod_ssl),
>
> I didn't make it clear earlier -- I do use the event mpm.
> Successfully. What *i
--- David Jones <[EMAIL PROTECTED]> wrote:
> zOS needs to compile with extra CFLAGS in order to link correctly.
> After revisions 153273/153266 to ./Makefile.in all compile and link flags
> are lost as
> buildmark.c is made without them:
concept sounds fine but...
> --- Makefile.in.orig Wed Jan
Jeff Trawick wrote:
I have been working with a user on one of these fork bomb scenarios
and assumed it was the child_init hook. But after giving them a test
fix that relies on a child setting scoreboard fields in child_main
before child-init hooks run, and also adds some debugging traces
relate
Markus Litz wrote:
Hello,
how can i get the filename only of the requested uri? For example if
"http://www.example.com/test.html"; is requestet, i only want "test.html".
request_rec::filename only gives the full filename on disk.
basename(r->filename)
Greg
Jeff Trawick wrote:
After a fix to prevent the fork bomb during slow child startup is
applied, something REALLY strange and completely unanticipated has to
happen to get the "scoreboard is full, not at MaxClients" message.
True?
true. no clue what else might trigger it at this point.
Jeff Trawick wrote:
There are problems accounting for child processes which are trying to
initialize that result in the parent thinking it needs to create more
children. The less harmful flavor is when it thinks (incorrectly) it
is already at MaxClients and issues the "reached MaxClients" messa
Paul Querna wrote:
The event mpm expects the apr_pollset backends to be based on epoll()
/ kqueue() or Solaris 10 event ports. What are the reasons because of
which poll() is not considered to be suitable for the event mpm ?
Is this because of the large number of fd's to be polled and linear
Saju Pillai wrote:
For a brand new client connection, why should there be 2 exchanges
between the listener thread and the worker thread before the request is
actually read ?
The client socket is accepted() and passed to a worker thread which runs
the create_connection hooks and marks the con
Paul Querna wrote:
This is traditionally called the 'Thundering Herd' Problem.
When you have N worker processes, and all N of them are awoken for an
accept()'able new client. Unlike the prefork MPM, N is usually a smaller
number in Event, because you don't need that many EventThreads Per
Num
Saju Pillai wrote:
I can understand why serializing apr_pollset_poll() & accept() for the
listener threads doesn't make sense in the event-mpm. A quick look
through the code leaves me confused about the following ...
>
It looks like all the listener threads epoll() simultaenously on the
li
Jeff Trawick wrote:
It isn't clear to me what an input filter should do about
Content-Length when it modifies the length of the body (assuming that
this isn't chunked encoding).
mod_cgi uses brigades to read the body but needs to look at
Content-Length before spawning the CGI script, so that
Scott A. Guyer wrote:
I would like to know more about the process
flow of the event MPM. The docs indicate it was largely
about moving listening logic for keep-alives out of the
worker threads and into the listener thread.
the basic concept of the event MPM is to reduce the amount of tim
Roy T. Fielding wrote:
On Oct 19, 2005, at 8:35 AM, Greg Ames wrote:
let's say it is a HEAD request for a local static file. the
default_handler calls ap_set_content_length which creates a C-L
header. but then the body could be run through some length changing
filter, such as mod_de
Roy T. Fielding wrote:
On Oct 18, 2005, at 3:58 PM, Greg Ames wrote:
Index: server/protocol.c
===
--- server/protocol.c (revision 326257)
+++ server/protocol.c (working copy)
@@ -1302,7 +1302,13 @@
* We can only set a C
...a.k.a. Windows Update doesn't work through an httpd-2.* proxy. it looks like a
regression from 1.3.
the interesting stuff happens in ap_content_length_filter. it calculates the new content
length by traversing the output brigade. but in this case, the brigade consists of only
an EOS buck
Brian Pane wrote:
I think one contributor to the event results is an issue that Paul Querna
pointed out on #httpd-dev the other day: apr_pollset_remove runs in O(n)
time with n descriptors in the pollset.
thanks, I see it. yeah we are going to have to do something about that.
Greg
Brian Akins wrote:
Basically, I was referring to the overall hits a box could serve per
second.
with 512 concurrent connections and about an 8k file, 2.1 with worker
served about 22k request/second. event served about 14k.
do you recall if CPU cycles were maxed out in both cases?
thanks,
Greg Ames wrote:
this is interesting to me because Brian Atkins recently reported that
s/Atkins/Akins/ sorry, Brian
Greg
Brian Pane wrote:
On Oct 10, 2005, at 12:01 AM, Paul Querna wrote:
If the content has already been generated, why add the overhead of
the context switch/sending to another thread? Can't the same event
thread do a non-blocking write?
Once it finishes writing, then yes, we do require a con
Brian Pane wrote:
With the batch of commits I did this weekend, the Event MPM in
the async-dev Subversion branch now does write completion
in a nonblocking manner.
very cool!
There are several more things that need to be fixed in order
to make the asynchronous write completion useful in a
p
[EMAIL PROTECTED] wrote:
use Greg's cleaner fix for CAN-2005-2970
Modified:
@@ -823,6 +818,7 @@
free(ti);
ap_scoreboard_image->servers[process_slot][thread_slot].pid = ap_my_pid;
+ap_scoreboard_image->servers[process_slot][thread_slot].tid =
apr_os_thread_current();
ap
Peter Djalaliev wrote:
Greg,
Thanks for the reply. Do you know where that would be in terms of the
source code of Apache? I went through most of the source code as much as I
could, but I didn't find anything. I expected it to be more visible.
I don't think you will find a place that looks f
Peter Djalaliev wrote:
Where does the Apache web server first detect that a request is over HTTPS?
I can't find the specific place in the source code where this is done
(assuming a specific place exists).
my (non-expert) guess: shortly after the request is mapped to an IP
based virtual host wh
Paul Querna wrote:
Brian Pane wrote:
On the subject of asynchronous write completion, I've drawn a
connection state model that
combines the current state transitions of the event MPM with new states
for write completion
and the handler phase.
Very cool diagram.
amen.
I see a tiny differ
Brian Pane wrote:
Rather than automatically setting TCP_NODELAY in core_pre_connection(),
perhaps we should set it conditionally in core_output_filter(), where
we have
enough information to tell whether it's needed.
I'm +1 on the concept of being more lazy about setting the sockopts. the
Greg Ames wrote:
Brian Pane wrote:
I'm eager to hear some feedback on this idea:
* Will it work? Or am I overlooking some design flaw?
it should work as long as everything important that happens after the
check_pipeline_flush call still gets done somehow. a quick glance at
the
Brian Pane wrote:
Looking at the pattern of calls to ap_core_output_filter() in the event
MPM, it occurred to me that it may be straightforward to hand off the
writing of the request to an async completion thread in a lot of useful
> real-world cases.
In function check_pipeline_flush() in
Paul Querna wrote:
once I got past that, it just worked. my tests were fairly simple. I
had pipelining enabled in mozilla and also created a script that did
HTTP/1.1 pipelining. if anyone can think of other scenarios I should
test with mod_ssl please let me know.
Yes... I believe it will
Joe Orton wrote:
You can create a self-signed cert for mod_ssl testing with just one
command: "openssl req -x509 -nodes -new -out foo.cert -keyout foo.key"
the docs are a bit too helpful there really.
thanks Joe! this looks like a time saver.
Greg
Paul Querna wrote:
Yes... I believe it will 'mostly' work, but the issue becomes tricky
once you consider the SSL protocol. The problem is we might have an
entire pipe-lined request buffered inside the SSL Packets, and
therefore, never trigger the socket to come out of the poll(). For
simple t
my biggest hurdle in getting the event MPM to work with mod_ssl was learning how
to create a self signed server cert with openssl.
http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#ownca is very good but refers
to a sign.sh script that I couldn't find in httpd-2.x . I assume sign.sh was
part o
I noticed that multiple packets are being sent to the network when one would do
on a couple of Linux 2.6.x boxes. one is SuSE SLES 9, the other is RHEL 4. the
first packet is all the HTTP headers, the second is the body/file. strace
http://people.apache.org/~gregames/rhel4.cork.strace reveals
Greg Ames wrote:
Brian Akins wrote:
We've been doing some testing with the current 2.1 implementation, and
it works, it just currently doesn't offer much advantage over worker
for us. If num keepalives == maxclients, you can't accept anymore
connections.
that'
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
William A. Rowe, Jr. wrote:
Will, can you help me understand your concern? this doesn't change the headers of the POST request. it only affects which new headers we generate for the new SSI GET subrequest.
Well I totally understand the issue - I'm blowing up in some PHP
code due to an earlier ph
1 - 100 of 601 matches
Mail list logo