Bojan Smojver wrote:
>I'm proposing to add two extra fields to request_rec structure:
>
>apr_off_t bytes_in
>apr_off_t bytes_out
>
>These babies would be used to record the number of bytes received and sent (on
>the wire) per each request. I'm writing a little filter module (with a lot of
>help
[EMAIL PROTECTED] wrote:
>__pthread_alt_unlock() loops through a list of threads that are blocked on a
>mutex to find the thread with the highest priority. I don't know which mutex
>this is; I'm guessing it's the one associated with worker's condition variable.
>The ironic thing is that for http
On Mon, 2002-09-16 at 23:32, Justin Erenkrantz wrote:
> On Mon, Sep 16, 2002 at 09:46:47AM -0700, Brian Pane wrote:
> > I disagree entirely. There's no need to let the API keep changing
> > continuously, especially not for the sake of "correctness." All of
&
On Mon, 2002-09-16 at 18:41, Sander Striker wrote:
> Hi,
>
> I've tagged and rolled 2.0.41. Please test the tarballs found
> at http://httpd.apache.org/dev/dist/ and cast thy votes.
The tarball looks good, functionally and performance-wise,
in my testing
+1 for GA
Brian
On Wed, 2002-09-11 at 07:40, Kris Verbeeck wrote:
> Hi,
>
> Attached is a patch that will solve the 304 turning into 200 response code
> problem. It seems that in mod_disk_cache the status line was also saved
> and restored from the cache. On a first request it is saved as "200 OK" or
> somethi
I tried to recreate this problem, but no luck so far...
is there any particular type of request that I need to
use to trigger the memory leak? I just ran a few hundred
thousand requests for the same 1KB file through 2.0.41-pre2
with the mod_mem_cache settings below, and I can't see
any sign of me
Joe Orton wrote:
>On Tue, Sep 10, 2002 at 09:21:17PM -0700, Justin Erenkrantz wrote:
>
>
>>On Tue, Sep 10, 2002 at 04:04:31PM -0700, Ian Holsman wrote:
>>
>>
>>>does anyone recall if there was a good reason not to include this patch
>>>in the main distribution ?
>>>
>>>
>>What patch i
On Tue, 2002-09-10 at 23:59, Sander Striker wrote:
> > From: Brian Pane [mailto:[EMAIL PROTECTED]]
> > Sent: 11 September 2002 04:32
>
> > Greg Ames wrote:
> >
> > >...since 10-Sep-2002 19:22:33 PDT. Looks good.
> > >
> > >Greg
> >
Thanks. There was a fix committed for this a couple of weeks
ago, so 2.0.41 will have the right logic.
Brian
Spinka, Kristofer wrote:
>Description:
>
> The Apache environment variable "gzip-only-text/html" was designed to
>allow control over whether non-text/html content will be c
Greg Ames wrote:
>...since 10-Sep-2002 19:22:33 PDT. Looks good.
>
>Greg
>
>
Does it have Justin's fix for the bucket leak (the one from earlier today)?
Brian
On Tue, 2002-09-10 at 04:12, Jeff Trawick wrote:
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > I like the idea of restricting the change to Tru64 for now, just
> > to eliminate the possibility of breaking something unexpected on
> > some other system this close to
David Hill wrote:
>For Tru64, the compiler defines two things, __alpha and __osf__ , either can
>be used, the __osf__ tends to be used more.
>So:
>
>#if HAVE_ALLOCA && defined(__osf__)
>
Thanks. I'll commit in a minute.
Brian
Dave Hill wrote:
>Hi all,
> While digging into that mysterious hang of Apache 2 on Tru64,
>I found that it seemed to be hanging under apr_poll in alloca()
>While I found that the problem seems to go away when not using a
>prerelease version of the OS, it did bring something to my attention
I just ran some CPU profiling tests on 2.0.41 (Sander's "PRE1" tag).
For those working on performance tuning and/or mod_cache development,
the results show a few significant opportunities for improvement.
Test case: httpd-2.0.41 on Linux 2.4/x86
prefork MPM
one client (ab
Cliff Woolley wrote:
>Can anyone confirm or deny this? Seems like it should be trivial to fix
>if correct.
>
I haven't seen that error case myself, but it's definitely
going to crash there if r->filename is null. I just checked
the code, and mod_proxy itself doesn't guarantee that
r->filename
Brian Pane wrote:
> Sander Striker wrote:
>
>> Hi,
>>
>> I tagged the tree today as STRIKER_2_0_41_PRE1. I'll do some
>> testing this weekend myself and will retag for release after
>> I get some positive feedback on this tag.
>>
>>
>>
Sander Striker wrote:
>Hi,
>
>I tagged the tree today as STRIKER_2_0_41_PRE1. I'll do some
>testing this weekend myself and will retag for release after
>I get some positive feedback on this tag.
>
>
>
Thanks, Sander. I've tested this tag successfully with
the leader/follower and prefork MPMs
Sander Striker wrote:
>Hi,
>
>I hereby volunteer to be RM for 2.0.41. (tag this weekend).
>Objections?
>
>Sander
>
>
+1 for tagging this weekend.
In the meantime, can the folks with repeatable mod_proxy memory
leak cases please try out the latest code in CVS to see if the
recent bucket cleanu
David Hill wrote:
>Hi all,
>I am seeing log messages saying "the listener thread didn't exit". This
>is coming out of the housekeeping stuff in the worker module. I am using
>2.0.40 and Tru64. I *think* it is happening when the server is trying to
>reduce surplus clients.
>
The worker MPM ha
Joe Schaefer wrote:
>There's also a refcount problem in http_protocol.c wrt chunked
>transfer codings. The problem is that the bucket holding the
>chunk size isn't ever freed, so the corresponding data block
>is overcounted.
>
>Here's a diff for http_protocol.c against current anon-cvs (which
>do
Peter Van Biesen wrote:
>Hi,
>
>I've recompiled the server with only the proxy and the core modules :
>
>But the problem remains :
>
>Does anybody have another idea for me to try ?
>
There was a fix for http_protocol.c last night that addressed
at least one problem that could cause the proxy
Cliff Woolley wrote:
>On Wed, 4 Sep 2002, Brian Pane wrote:
>
>
>
>>That's not guaranteed. The API, as currently documented, only
>>guarantees that it will return an apr_bucket_brigade*, not that
>>it will be non-null.
>>
>>
>
>It'
Cliff Woolley wrote:
>On 5 Sep 2002 [EMAIL PROTECTED] wrote:
>
>
>
>> bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
>> +if (bb == NULL) {
>> +r->connection->keepalive = AP_CONN_CLOSE;
>> +return -1;
>> +}
>>
>>
>
>apr_brigade_create() will
Cliff Woolley wrote:
>Bottom line: the size of c->bucket_alloc will be based on the max number
>of buckets and bucket buffers you've had allocated at one time. The
>answer is almost certainly that apr_bucket_destroy() is not being called
>on some bucket that you're actually finished with. This
Peter Van Biesen wrote:
>If you are talking about the memory leak when downloading large files
>through a proxy chain, this problem was first observed in version
>2.0.39, so it probably isn't the same problem.
>
2.0.39 definitely would have had problems with large requests
due to the way its con
Aaron Bannert wrote:
>On Wed, Sep 04, 2002 at 06:06:59PM +0200, Graham Leggett wrote:
>
>
>>Is it possible to read brigades from two filter stacks simultaneously?
>>
>>
>
>No, and the need for multiplexed brigade read/writes has been
>brought up before, but never fully designed nor implemen
Graham Leggett wrote:
>> For the expiration case, there's a much easier solution than
>> shadowing the
>> incomplete response. Add a new state for cache entries:
>> "being_updated."
>> When you get a request for a cached object that's past its expiration
>> date,
>> set the cache entry's stat
Paul J. Reder wrote:
>
>
> Brian Pane wrote:
>
>> I've been thinking about strategies for building a
>> multiple-connection-per-thread MPM for 2.0. It's
>> conceptually easy to do this:
>>
>> * Start with worker.
>>
>> * Keep th
[EMAIL PROTECTED] wrote:
>On Tue, 3 Sep 2002, Chris Taylor wrote:
>
>
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>
>>
>>>[ ] Check in aaa rewrite to 2.0.
>>>[X] Check in aaa rewrite to 2.1.
>>>
>>>
>>My view is that it's important to keep 2.0 stable to attract new
>>users
Justin Erenkrantz wrote:
>Please vote:
>
>[X] Check in aaa rewrite to 2.0.
>[ ] Check in aaa rewrite to 2.1.
>
>
Graham Leggett wrote:
> Brian Pane wrote:
>
>> In the "shawowing" case, we'd also need a way for all the requests
>> reading from the same incomplete cache entry to block if they reach
>> the end of the incomplete cached brigade without seeing EOS.
Graham Leggett wrote:
> Bill Stoddard wrote:
>
>> Adding a callback/hooks sounds okay. An additional problem to
>> consider is
>> when a frequently requested resource does not return an EOS in the firet
>> brigade and it turns out to be too large for the cache. We need a
>> negative
>> cache (
This patch allows mod_cache to cache a response that isn't
all contained in the first brigade sent through cache_in_filter().
(This scenario happens, for example, with reverse-proxy requests,
CGIs, and various app server connectors.)
Can someone familiar with the caching code please scrutinize
th
e latest 2.0.41-dev
code, and it properly streamed large responses without buffering,
but I'm not certain that my test case covered all the code paths
involved in your two-proxy setup.
Thanks,
Brian
>
>Peter.
>
>Graham Leggett wrote:
>
>
>>Brian Pane wrote:
>
Graham Leggett wrote:
> Peter Van Biesen wrote:
>
>> I now have a reproducable error, a httpd which I can recompile ( it's
>> till a 2.0.39 ), so, if anyone wants me to test something, shoot ! Btw,
>> I've seen in the code of ap_proxy_http_request that the variable e is
>> used many times but I c
Cliff Woolley wrote:
>On Sat, 31 Aug 2002, Brian Pane wrote:
>
>
>
>>Wouldn't it be sufficient to guarantee that:
>> * each *bucket* can only be processed by one thread at a time, and
>> * allocating/freeing buckets is thread-safe?
>>
>>
>
Cliff Woolley wrote:
>On Sat, 31 Aug 2002, Brian Pane wrote:
>
>
>
>>I don't think we can count on the assumption that each conn will
>>only be processed by one thread at a time. For example, this race
>>
>>
>
>Then we have to at least guaran
Cliff Woolley wrote:
>On Sat, 31 Aug 2002, Brian Pane wrote:
>
>
>
>> * The bucket allocator alloc/free code isn't
>>thread-safe, so bad things will happen if the
>>writer thread tries to free a bucket (that's
>>just been written to th
I've been thinking about strategies for building a
multiple-connection-per-thread MPM for 2.0. It's
conceptually easy to do this:
* Start with worker.
* Keep the model of one worker thread per request,
so that blocking or CPU-intensive modules don't
need to be rewritten as state mac
Justin Erenkrantz wrote:
>On Fri, Aug 30, 2002 at 10:17:52AM -0700, Aaron Bannert wrote:
>
>
>>No, that's exactly the problem we have with 1.3 right now. There *are*
>>people who are willing to backport fixes and even features to the 1.3
>>tree, it's only a faction of the group here that *doesn
[EMAIL PROTECTED] wrote:
>Well, my main concern is if there are things down the line which buffer large
>portions of data before sending them out, it would generate "bursty" network
>traffic, which I want to avoid. Part of the reason I'm doing this is because I
>want to have more smooth control
[EMAIL PROTECTED] wrote:
>r->bytes_sent needs to be just content data to be backwards
>compatible. As for two fields to get the information, I am not sure why
>we need two fields.
>
We need two fields in order to compute r->bytes_sent in the first place.
If we compute r->bytes_sent based on c->
Bojan Smojver wrote:
>On Thu, 2002-08-22 at 09:03, [EMAIL PROTECTED] wrote:
>
>
IMO, the best solution is to move the bytes_sent information to the
conn_rec, and have the protocol module reset it whenever it wants to. For
backwards compat, it would be REALLY cool, if the r->bytes_s
[EMAIL PROTECTED] wrote:
>The cleanest solution, is to move the bytes_sent to the conn_rec, but then
>it should really be per-connection, not per-request, and we want it to be
>per-request.
>
>The other solution is to have the core figure out the correct amount of
>data in the core_output_filter
[EMAIL PROTECTED] wrote:
>On Wed, 21 Aug 2002, Brian Pane wrote:
>
>
>
>>[EMAIL PROTECTED] wrote:
>>
>>
>>
>>>To solve the original problem, just look for ap_check_pipeline_flush, and
>>>around that function (or in the core's lo
[EMAIL PROTECTED] wrote:
>To solve the original problem, just look for ap_check_pipeline_flush, and
>around that function (or in the core's log_transaction phase), just reset
>c->bytes_sent to 0. If you do it in the core's log_transaction phase,
>just make sure that the function is registered AP
Justin Erenkrantz wrote:
>On Wed, Aug 21, 2002 at 12:27:29AM -0700, Brian Pane wrote:
>
>
>>The remaining problem is: how can we identify the request_rec from
>>within core_output_filter()? Within that filter, f->r is NULL. I
>>have some ideas for solving this b
Bojan Smojver wrote:
>Quoting Brian Pane <[EMAIL PROTECTED]>:
>
>
>
>>I think it's easy to solve the keepalive problem: core_output_filter()
>>just needs to set r->bytes_sent as soon as it sees the EOS, rather than
>>waiting until it writes
Justin Erenkrantz wrote:
>>Everything here (core_output_filter) revolves around apr_brigade_write
>>and local variable n, which looks like the number of bytes that are
>>about to go down the pipe:
>>
>>- to establish the total, we do:
>>
>> f->r->bytes_sent += n;
>>
>> after each write
>>
>>All
[EMAIL PROTECTED] wrote:
>>To solve the problem that Blaise noted, I believe we'll have to
>>make the content_length filter stop reading buckets altogether
>>(which I think is absolutely the right thing to do, but we'll
>>have to find some other place to compute r->bytes_sent).
>>
>>
>
>Compu
Bill Stoddard wrote:
>>Brian Pane writes:
>> > Blaise Tarr wrote:
>> >
>> > >With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
>> > >streamed to the client but sent in one big chunk.
>> >
>> > Here's a pat
Blaise Tarr wrote:
>With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
>streamed to the client but sent in one big chunk. It appears that the
>C-L filter now buffers the data in every case. For certain
>applications this is a very undesirable feature, and it would be very
>helpf
Rodent of Unusual Size wrote:
>We had this discussion elsewhere, but just for the record..
>
>Justin Erenkrantz wrote:
>
>
>>And, my point back to you is that should be part of the documentation
>>of the module NOT of httpd-2.0.
>>
>>
>
>IMNSHO, that is *such* BS. If someone has a working
[Posting for comments before I commit, because the
core filter code is somewhat complex...]
With the current core_output_filter() implementation,
if the client requests a file smaller than 8KB, the
filter reads the file bucket, makes a copy of the
contents, and sets the copy aside in hopes of bei
Blaise Tarr wrote:
>With 2.0.40 content coming from mod_proxy and mod_cgi is no longer
>streamed to the client but sent in one big chunk. It appears that the
>C-L filter now buffers the data in every case.
>
I believe this is due to the code in the content-length filter that
tries to buffer up
Gabriel Ambuehl wrote:
>Hi Rasmus Lerdorf,
>you wrote.
>
>
>
>>>time spent in mutex-protected code is 99% of the total request processing
>>>time, then the server will scale poorly. The key success factor is to not
>>>use libraries that require locking for lengthy operations.
>>>
>>>
>RL
Rasmus Lerdorf wrote:
>>Hi Rasmus Lerdorf,
>>you wrote.
>>
>>RL> libraries as well. We are going to have to fix a bunch of them and mutex
>>RL> some others before Apache2 with a threaded MPM will be of any use with PHP
>>RL> or mod_perl.
>>
>>Am I correct assuming that when they are mutex'ed tha
Gabriel Ambuehl wrote:
>Hi Rasmus Lerdorf,
>you wrote.
>
>RL> libraries as well. We are going to have to fix a bunch of them and mutex
>RL> some others before Apache2 with a threaded MPM will be of any use with PHP
>RL> or mod_perl.
>
>Am I correct assuming that when they are mutex'ed that there
Ian Holsman wrote:
> I'm just looking through the fdqueue code again, and I noticed that we
> are signaling the !empty condition
> on every push, regardless if we were empty or not, is there a good
> reason to do this, instead of checking if
> we are empty and then doing the signal?
It shoul
Jeff Trawick wrote:
>Ian Holsman <[EMAIL PROTECTED]> writes:
>
>
>
>>with the recent fix to apr_poll's memory leak we can start this ball
>>rolling again..
>>
>>
>
>We'll need to state that it can't be used with > x Listen statements
>or explain how to build APR to allow more descriptors wi
Ian Holsman wrote:
> with the recent fix to apr_poll's memory leak we can start this ball
> rolling again..
>
> I'll tag the 2.0.40 as the existing stuff tagged + this poll.
>
> is there any other small patches which need/should go into 40 since I
> last tagged ?
I can think of a few things t
Greg Ames wrote:
>[EMAIL PROTECTED] wrote:
>
>
>
>> +* Performance problems in the content-length filter:
>>
>>
>
>
>
>> + - In addition, the C-L filter reads and buffers all the
>> +content from a pipe bucket.
>>
>>
>
>What could we do instead? Punt on the length
[EMAIL PROTECTED] wrote:
>On 17 Jul 2002 [EMAIL PROTECTED] wrote:
>
>
>
>>trawick 2002/07/17 15:15:01
>>
>> Modified:.STATUS
>> Log:
>> somebody please tell me I don't know how to read C code anymore
>>
>> (I guess the pool for an Apache socket will grow on every read/writ
Justin Erenkrantz wrote:
>On Wed, Jul 17, 2002 at 01:48:52PM -0500, William A. Rowe, Jr. wrote:
>
>
>>Attached is a patch that should allow ap_get_brigade() modules to
>>determine EOS on the same roundtrip as the last read of the request
>>body contents.
>>
>>
>
>+1. -- justin
>
I haven't
> -apr_sleep(apr_time_from_sec(1));
> +apr_sleep(apr_time_from_sec(1) - apr_time_now());
The result of that subtraction is roughly negative one billion.
--Brian
On Mon, 2002-07-15 at 01:13, Sander Striker wrote:
> Doesn't this change make us sleep a full second now, instead of the
> remainder of the current second?
>
> Sander
>
Yes, but it only happens once, during startup, so it doesn't
matter much.
--Brian
> > From: [EMAIL PROTECTED] [mailto:[EMAIL
Aaron Bannert wrote:
>On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote:
>
>
>>It's
>>unreasonable to make the every admin responsible for hacking
>>their start scripts to work around our broken product.
>>
>>
>
>In what way is o
Aaron Bannert wrote:
>I really don't like this. It adds unnecessary complexity to the configure
>script,
>
There's nothing unnecessary about it.
> misleads admins in to thinking that they have to rerun configure
>to set the file limit,
>
No, nowhwere do we say "you have to rerun configure to s
Ryan Bloom wrote:
>>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
>>
>>At 02:51 AM 7/14/2002, you wrote:
>>
>>
>>>Currently, the content-length filter attempts to compute the length
>>>of the entire response before passing any data on to the next filter,
>>>and it sets request_rec->by
On Sun, 2002-07-14 at 09:35, Cliff Woolley wrote:
> On Sun, 14 Jul 2002, Brian Pane wrote:
>
> > For example, given a .shtml file that includes several small,
> > non-parsed files, the setaside logic in the C-L filter will do
> > an mmap+memcpy+munmap of ea
Currently, the content-length filter attempts to compute the length
of the entire response before passing any data on to the next filter,
and it sets request_rec->bytes_sent to the computed content-length.
This is bad for several reasons:
* The C-L filter needs to know the length of every buck
Ryan Bloom wrote:
>I know that there has been some talk of doing a release next week. I
>just ran my test suite, and we seem to be failing some mod_access
>checks. I think it has to do with the table re-write, but I haven't
>looked at it in enough detail to be 100% sure. Is anybody else seeing
>
>
>Shlib Subroutine Source File Visit Enter % Ticks
> === = = =
>.apr_palloc apr_pools.c 7878 2.9 1404
>.__is_wctype_std libc/__is_wctype_std.c 66
Bill Stoddard wrote:
>Subroutine Name Source File Visit Enter % Ticks
>=== === = = =
>.ap_rgetline_coreprotocol.c 366 1.5 709
>
Darn, all that optimization work and it's
Aaron Bannert wrote:
>On Wed, Jul 10, 2002 at 10:44:46AM -0700, Ryan Bloom wrote:
>
>
>>I still believe that everything that is currently in ROADMAP can and
>>should be implemented in 2.0.
>>
I agree.
>And my point is we won't know until there is a patch that solves
>one of the roadmap proble
On Wed, 2002-07-10 at 04:16, Jeff Trawick wrote:
> Brian Pane <[EMAIL PROTECTED]> writes:
>
> > This patch increases the maximum number of open files
> > at httpd startup. Before I commit, does anyone have a
> > scenario in which it won't be safe to do t
Bill Stoddard wrote:
>>William A. Rowe, Jr. wrote:
>>
>>
>>
>>>At 12:18 PM 7/9/2002, Bill Stoddard wrote:
>>>
>>>
>>>
>I'm going to do a start the T&R process on thursday for a 2.0.40
>
>
release
>so if you've got things which you want in
Bill Stoddard wrote:
>>William A. Rowe, Jr. wrote:
>>
>>
>>
>>>At 12:18 PM 7/9/2002, Bill Stoddard wrote:
>>>
>>>
>>>
>I'm going to do a start the T&R process on thursday for a 2.0.40
>
>
release
>so if you've got things which you want i
William A. Rowe, Jr. wrote:
> At 12:18 PM 7/9/2002, Bill Stoddard wrote:
>
>> > I'm going to do a start the T&R process on thursday for a 2.0.40
>> release
>> > so if you've got things which you want in there and are stable
>> > (apr_poll) comes to mind please commit them.
>> >
>> > Ian
>>
>> I'
This patch increases the maximum number of open files
at httpd startup. Before I commit, does anyone have a
scenario in which it won't be safe to do this?
Thanks,
--Brian
Index: os/unix/unixd.c
===
RCS file: /home/cvs/httpd-2.0/os/
Jeff Trawick wrote:
>This is from line 837, as we bail out with 400 error:
>
>(gdb) dump_table tmp_headers
>[0] 'Host'='127.0.0.1'
>[1] 'Accept-Encoding'=''
>
>I think the problem is that the code now expects that a continuation
>line starts with a tab. That is not the case in this testcase.
>Ne
On Mon, 2002-07-08 at 07:52, Jeff Trawick wrote:
> This request used to work fine, and mod_gzip worked its magic as long
> as the configuration was okay:
>
> "GET /manual/mod/mod_rewrite.html.en HTTP/1.1\r\nHost: 127.0.0.1\r\nAccept-Encoding:
> \r\n gzip\r\n\r\n"
There's new parsing logic
On Sat, 2002-07-06 at 23:31, Sebastian Bergmann wrote:
> Brian Pane wrote:
> > It may be unsafe to cast to a long when the arg is a "%qd". How
> > about this:
>
> Compiles as well :)
Thanks, I've just committed the change.
--Brian
On Sat, 2002-07-06 at 23:07, Sebastian Bergmann wrote:
> Juergen Heckel wrote:
> > Replacing the ab.c with an older version solves this little problem.
>
> Index: support/ab.c
> ===
> RCS file: /home/cvspublic/httpd-2.0/support/ab.c,
Justin Erenkrantz wrote:
>On Sat, Jul 06, 2002 at 12:09:40PM -0700, Ryan Bloom wrote:
>
>
>>Pay attention to what that message says please. It says "The filter
>>should always be in the stack, and it should always collect
>>information." It doesn't say "The filter should always be touching th
On Sat, 2002-07-06 at 12:09, Ryan Bloom wrote:
> > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> >
> > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote:
> > > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> > > > Of course, in the common case of a static file with no filte
On Sat, 2002-07-06 at 12:09, Ryan Bloom wrote:
> > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> >
> > On Sat, Jul 06, 2002 at 08:25:18AM -0700, Ryan Bloom wrote:
> > > > From: Justin Erenkrantz [mailto:[EMAIL PROTECTED]]
> > > > Of course, in the common case of a static file with no filte
On Wed, 2002-07-03 at 20:07, Ryan Bloom wrote:
> > From: Brian Pane [mailto:[EMAIL PROTECTED]]
> >
> > On Wed, 2002-07-03 at 15:26, Ryan Bloom wrote:
> > > How big a problem is this really? Most of the time, the
> content-length
> > > filter isn't
[EMAIL PROTECTED] wrote:
>stoddard2002/07/05 19:49:59
>
> Modified:modules/arch/win32 mod_win32.c
> modules/experimental mod_mem_cache.c
> Log:
> Fix some Win32 compile breaks caused by Brian Pane's making apr_table_t
> a full incomplete type.
>
Sorry about that. Thank
On Wed, 2002-07-03 at 15:26, Ryan Bloom wrote:
> How big a problem is this really? Most of the time, the content-length
> filter isn't supposed to actually buffer the brigade. It should only be
> doing the buffering if we are doing a keepalive request and we can't do
> chunking.
I'm seeing the
I'm working on a fix to keep file buckets from being mmaped when
they're set aside. (The motivation for this is to eliminate the
bogus mmap+memcpy+munmap that happens when a client requests a
file smaller than 8KB over a keep-alive connection.)
The biggest problem I've found is that the scalabil
This patch uses the same temp brigade to read all the lines of
an HTTP request, in order to eliminate the overhead of brigade
creation and destruction that we've seen in recent performance
profiling. The patch changes the signature of ap_rgetline_core()
and adds a new ap_get_mime_headers_core(),
On Tue, 2002-07-02 at 21:09, Bill Stoddard wrote:
> .ap_rgetline_coreprotocol.c3.32 6 1.4 3428
I'll try the persistent-temp-brigade approach for ap_rgetline_core()
to see how much it helps.
> .get_filter_handle util_filter.c 4.62 2 1.1
Bill Stoddard wrote:
>Subroutine Name Source File Ratio Enter %
>Cycles
>=== === = =
>==
>.core_input_filter core.c3.15 11 1.5 3628
>.ap_rgetline_coreprotocol.c
On Sun, 2002-06-30 at 22:04, Justin Erenkrantz wrote:
>
> > +0. If we create the temp brigade in ap_get_mime_headers(), we'll
> > still be doing the brigade creation/deletion for the first line of
> > the request. We really need to create the temp brigade in
> > ap_read_request(), and then pa
On Sun, 2002-06-30 at 21:30, Justin Erenkrantz wrote:
> On Sun, Jun 30, 2002 at 09:14:20PM -0700, Brian Pane wrote:
> > The brigade can't be in a filter context, because then it wouldn't be
> > accessible from ap_rgetline_core(). The request_rec is the only place
>
On Sun, 2002-06-30 at 20:57, Justin Erenkrantz wrote:
> On Fri, Jun 28, 2002 at 07:01:34PM -0700, Ryan Bloom wrote:
> > Have you looked at which of these are causing the most performance
> > problems? It seems to me that the easiest thing to do, would be to use
> > a persistent brigade, which rem
On Fri, 2002-06-28 at 19:01, Ryan Bloom wrote:
> > From: Brian Pane [mailto:[EMAIL PROTECTED]]
> >
> > One of the biggest remaining performance problems in the httpd is
> > the code that scans HTTP requests. In the current implementation,
> > read_request_line()
On Sun, 2002-06-30 at 01:34, Justin Erenkrantz wrote:
> It'd have to be a connection-level filter to ensure that we don't
> lose pipelined-requests since we read too much. But, since we are
> a connection-level filter, that means you don't have access to
> the request. So, you'd have to split
On Sat, 2002-06-29 at 23:57, Justin Erenkrantz wrote:
> Reading the headers as an input filter could be too late for
> request processing as that could be done as late as the handlers.
It will happen long before then: ap_read_request() causes a read
on the input filter chain at the start of the
201 - 300 of 701 matches
Mail list logo
