Re: Dumb APR_BUCKET_BUFF_SIZE question
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote: Why is it hardcoded to be 8000? It would seem like you could easily be unlucky and just miss the cutoff and end up with a 6000 byte heap bucket followed by a 3000 byte transient bucket, for example, as a result of 3 3000 byte ap_rwrites. For that particular case it might be quite beneficial to increase APR_BUCKET_BUFF_SIZE to 9000 which would suggest that it might be something that should be configurable. It was at some point I think :-) But at 8k it happens to fit on some intelish architectures in a common page of 8k (8192 bytes). I would not mind to see if much more configurable run-time -and- auto detecting compile time; we've got great improvements on some arch's with 16k pages -and- by fiddling with it so that it also happens to fit in a nice DMA multiple of the ethernetcard. Dw.
Re: Dumb APR_BUCKET_BUFF_SIZE question
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote: I still think it would be worthwhile to make it configurable. Linux or FreeBSD5 on IA64 with 16k pages, for example, might show some decent gains by setting that to 15000. Or do a getpagesize() call on startup to determine it dynamically. It might be. We've considered having it be configurable before. There are just a lot of implications in changing the value; for example, it affects the memory footprint of the server, it affects how much data gets read in to memory per read() call on a file bucket (which might alter the decision of whether read() or mmap() is preferable, for example), it affects how well the data fits into memory pages, and it affects how much data is buffered in one block for the scenarios you described. There are probably others I'm not thinking of right now, too. Lots of different axes that must be considered when trying to pick an optimal value. But still, if you want to make it configurable, go right ahead. :)
Re: Dumb APR_BUCKET_BUFF_SIZE question
Cliff Woolley wrote: It might be. We've considered having it be configurable before. There are just a lot of implications in changing the value; for example, it affects the memory footprint of the server, it affects how much data gets read in to memory per read() call on a file bucket (which might alter the decision of whether read() or mmap() is preferable, for example), it affects how well the data fits into memory pages, and it affects how much data is buffered in one block for the scenarios you described. There are probably others I'm not thinking of right now, too. Lots of different axes that must be considered when trying to pick an optimal value. But still, if you want to make it configurable, go right ahead. :) Right, I saw all the things it affected which was precisely why I wondered why it wasn't made configurable. I can see perhaps protecting users from themselves, but other parts of Apache2 doesn't really follow that. The WindowSize config option in mod_deflate would be a very bad idea to change away from the default of 15, for example. Anyway, I will go play a bit with the bucket size on 64-bit boxes. -Rasmus
Dumb APR_BUCKET_BUFF_SIZE question
Why is it hardcoded to be 8000? It would seem like you could easily be unlucky and just miss the cutoff and end up with a 6000 byte heap bucket followed by a 3000 byte transient bucket, for example, as a result of 3 3000 byte ap_rwrites. For that particular case it might be quite beneficial to increase APR_BUCKET_BUFF_SIZE to 9000 which would suggest that it might be something that should be configurable. -Rasmus
Re: Dumb APR_BUCKET_BUFF_SIZE question
On Fri, 7 Jan 2005, Rasmus Lerdorf wrote: Why is it hardcoded to be 8000? It would seem like you could easily be unlucky and just miss the cutoff and end up with a 6000 byte heap bucket followed by a 3000 byte transient bucket, for example, as a result of 3 3000 byte ap_rwrites. For that particular case it might be quite beneficial to increase APR_BUCKET_BUFF_SIZE to 9000 which would suggest that it might be something that should be configurable. In fact, it used to be 9000. Then we realized that that was causing cache/page alignment problems. So we changed it to be just a fuzz less than 8KB to allow it plus the bucket allocator structures to fit into one 8KB or two 4KB pages. --Cliff
Re: Dumb APR_BUCKET_BUFF_SIZE question
Cliff Woolley wrote: On Fri, 7 Jan 2005, Rasmus Lerdorf wrote: Why is it hardcoded to be 8000? It would seem like you could easily be unlucky and just miss the cutoff and end up with a 6000 byte heap bucket followed by a 3000 byte transient bucket, for example, as a result of 3 3000 byte ap_rwrites. For that particular case it might be quite beneficial to increase APR_BUCKET_BUFF_SIZE to 9000 which would suggest that it might be something that should be configurable. In fact, it used to be 9000. Then we realized that that was causing cache/page alignment problems. So we changed it to be just a fuzz less than 8KB to allow it plus the bucket allocator structures to fit into one 8KB or two 4KB pages. I still think it would be worthwhile to make it configurable. Linux or FreeBSD5 on IA64 with 16k pages, for example, might show some decent gains by setting that to 15000. Or do a getpagesize() call on startup to determine it dynamically. -Rasmus
RE: APR_BUCKET_BUFF_SIZE question
This is the same issue I was dealing with in mod_proxy that I submitted the patch for in 'BUG 19954 [PATCH] HTTP tunneling through reverse proxy does not always work'. In my case I didn't care what the read size was, but I needed to forward on whatever had been read, even if it was less than 8000 bytes. Obviously, the patch I submitted was specific to mod_proxy, but the root issue is the same. - Chris Conti [EMAIL PROTECTED] [EMAIL PROTECTED] The buffer size is not 8K... it's 8000. 8K is what's actually allocated, ... I still don't see what problem you're trying to solve, though, by wanting a configurable buffer size? --Cliff
APR_BUCKET_BUFF_SIZE question
Title: APR_BUCKET_BUFF_SIZE question So currently Apache reads from the socket in APR_BUCKET_BUFF_SIZE chunks (8000 bytes by default) This value is a compiled value and can not be changed or configure at runtime. I was wondering if there is a particular reason not to make this configurable in some way. I was looking at the code and was thinking about a very simple way where we can read in larger or smaller chunks. I does not seems like a lot of code to change but I may be missing something. So the way I would deal with this is first: Make the apr_recv len parameter an input/output parameter instead of an output parameter so we can tell it how much data we would like to read. So if I set the value of len to something greater than 0 it would use that value. If len is zero or less it would use APR_BUCKET_BUFF_SIZE. In the code input filter, set the len value to readbytes or a configure value, or if not use APR_BUCKET_BUFF_SIZE. So we could have something like: ReadBufferSize 8000 Or ReadBufferSize 2000 Or ReadBufferSize Dynamic # This will use the readbytes value instead. That way a filter could ask for more or less bytes than the 8K. This seems awfully simple and I'm sure I'm missing something to why we don't do this already. Can somebody shed some light on this one? Juan
Re: APR_BUCKET_BUFF_SIZE question
On Wed, 9 Jul 2003, Juan Rivera wrote: That way a filter could ask for more or less bytes than the 8K. That's what apr_brigade_partition() is for. Does that not get you what you want? And anyway, having a runtime-configurable buffer size would make the bucket allocator WAY more complicated and less efficient... --Cliff
Re: APR_BUCKET_BUFF_SIZE question
Juan Rivera [EMAIL PROTECTED] writes: [...] That way a filter could ask for more or less bytes than the 8K. A filter can ask now- it just won't get more than 8K per ap_get_brigade call. FWIW, I think the best approach would be to put a loop in httpd-2.0/server/core.c's core_input_filter(), that would at least provide the core input filter with the ability to yield brigades with more than one (8K) bucket. -- Joe Schaefer
RE: APR_BUCKET_BUFF_SIZE question
Title: RE: APR_BUCKET_BUFF_SIZE question I figured it has to do something with the way pools work. Would it make a difference if the buffer size used is always a multiple of APR_BUCKET_BUFF_SIZE? Like 16, 32, 64? Do you know where the 8K number come from? Is it an empirical number or a theoretical one? -Original Message- From: Cliff Woolley [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 09, 2003 6:25 PM To: '[EMAIL PROTECTED]' Subject: Re: APR_BUCKET_BUFF_SIZE question On Wed, 9 Jul 2003, Juan Rivera wrote: That way a filter could ask for more or less bytes than the 8K. That's what apr_brigade_partition() is for. Does that not get you what you want? And anyway, having a runtime-configurable buffer size would make the bucket allocator WAY more complicated and less efficient... --Cliff
RE: APR_BUCKET_BUFF_SIZE question
On Wed, 9 Jul 2003, Juan Rivera wrote: I figured it has to do something with the way pools work. Nope, buckets don't allocate anything from pools. Would it make a difference if the buffer size used is always a multiple of APR_BUCKET_BUFF_SIZE? Like 16, 32, 64? Lots of the code assumes that things will be done in APR_BUCKET_BUFF_SIZE increments at the most. If you go in multiples of that, it means multiple buckets. The reason is that the bucket allocator hands out 8KB blocks. One of them it carves up into little hunks (I forget how big little is exactly, but it's something on the order of 64 bytes), and the others it hands out as-is. Do you know where the 8K number come from? Is it an empirical number or a theoretical one? The buffer size is not 8K... it's 8000. 8K is what's actually allocated, but some of that is used internally by the bucket allocator. The reason is that 4KB or 8KB tend to be the size of VM pages. We went with 8KB to try to balance computational overhead with memory overhead. I still don't see what problem you're trying to solve, though, by wanting a configurable buffer size? --Cliff
