Re: apr_strcat optimization(s)

bly a million times more useful than returning the result again. (you can see i stuck my_stpcpy() into mod_test_util_uri.c ... of course it's not a nicely optimised inline version :) -dean On Tue, 17 Jul 2001, dean gaudet wrote: > you might as well memcpy() if you're going to strlen()

Re: apr_strcat optimization(s)

you might as well memcpy() if you're going to strlen() first. it's less complex inline code. -dean On Tue, 19 Jun 2001, Doug MacEachern wrote: > the current apr_strcat does strlen() twice for each argument, this patch > makes it happen just once. it would also be handy to have an apr_pstrcatn

Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded

On Tue, 17 Jul 2001, Aaron Bannert wrote: > On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote: > > On Sun, 15 Jul 2001, Sander Striker wrote: > > > > > Why are we so desperate in opting out the child-pool creation? > > > I don't really have prob

Re: [PATCH] performance fixes for number formatting

you might want to disassemble the functions in gdb (or using objdump) to make sure that gcc emits a single division instruction for the "x / 10", "x % 10" expressions -- i forget the cases where it can and can't do this. the low level div instruction is a two result opcode, quotient and remainder.

Re: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded

, passing it > > the pthread_t from the other thread. > > > > Unfortunately, this is not a part of APR because many of the current OS > > implementations of this mechanism will leak resources (aparently in the > > kernel), and that is bad. > > > > -aaron

Re: DCEthreads - cancellation / mutexes is possible

On Tue, 17 Jul 2001, Justin Erenkrantz wrote: > And, from what I can tell, Dean Gaudet has mentioned this morning that > he is willing to veto async notification. Dean, would that include > cancellation of threads? I have a suspicion it might. Dean has > commit access on httpd as

Re: DCEthreads - cancellation / mutexes is possible

On Tue, 17 Jul 2001, Luke Kenneth Casson Leighton wrote: > therefore, i conclude that the dce/rpc codebase has successfully > implemented thread cancellation in their POSIX/Draft4 thread > library. yes cancellation is in the spec. i've never denied that. the problem is libraries and code over

Re: Inheritable APR handles.

On Tue, 17 Jul 2001, William A. Rowe, Jr. wrote: > Fine... but does that mean we don't want to actually clean out the > dozens of file descriptors that aren't needed from a threaded parent > process when we spawn a child (such as a CGI)? we do already (or we're supposed to) through all the child

Re: Seperating cleanups from memory allocations, WAS: RE: Terminatingthreads in a process

On Wed, 18 Jul 2001, Sander Striker wrote: > Wouldn't it be wiser to implement cleanup management as a > seperate entity, instead of piggy backing it on allocators? i'm not sure... 'cause the only thing i think which is missing is something like this: typedef struct { int die_soon_p

Re: Inheritable APR handles.

i object... reasons found in a message i just sent to apr-dev (at least i don't think it went to new-httpd). the fd inheritance through fork() is one of unix's warts, and it doesn't really need to be emulated... -dean On Sat, 14 Jul 2001 [EMAIL PROTECTED] wrote: > This patch begins to implemen

Re: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded

On Tue, 17 Jul 2001, Aaron Bannert wrote: > On Tue, Jul 17, 2001 at 01:29:47AM -0700, dean gaudet wrote: > > On Sun, 15 Jul 2001, Sander Striker wrote: > > > > > Why are we so desperate in opting out the child-pool creation? > > > I don't really have prob

Re: request_rec question

see modules/mappers/mod_negotiation.c search for "fast redirect". no comment on how clean this is :) it's something that should be moved to a core routine. -dean On Tue, 17 Jul 2001, Brian Pane wrote: > Is there anything that actually uses the > headers_out or err_headers_out fields in > the

Re: [PATCH] performance fixes for number formatting

you might want to disassemble the functions in gdb (or using objdump) to make sure that gcc emits a single division instruction for the "x / 10", "x % 10" expressions -- i forget the cases where it can and can't do this. the low level div instruction is a two result opcode, quotient and remainder.

Re: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded

, passing it > > the pthread_t from the other thread. > > > > Unfortunately, this is not a part of APR because many of the current OS > > implementations of this mechanism will leak resources (aparently in the > > kernel), and that is bad. > > > > -aaron

RE: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded

On Sat, 14 Jul 2001, Sander Striker wrote: > The way I see it, each process has a single pool instance as the parent > for all the threads. Resetting or destroying that pool should effectively > kill all threads. What am I missing? how does a thread kill another thread? -dean

RE: Terminating threads in a process, WAS: RE: [PATCH] Problems with MPM threaded

On Sun, 15 Jul 2001, Sander Striker wrote: > Why are we so desperate in opting out the child-pool creation? > I don't really have problems with a child pool for each thread. Actually, > it will make the dynamic locking a lot easier to implement if it stays. all threads MUST have their own private

Re: Terminiting threads in a process RE: [PATCH] Problems with MPM threaded

On Sat, 14 Jul 2001, Aaron Bannert wrote: > On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote: > > On Sat, 14 Jul 2001, Sander Striker wrote: > > > The way I see it, each process has a single pool instance as the parent > > > for all the threads. Resetting or destroying that pool s

Re: [PATCH] Problems with MPM threaded

On Sat, 14 Jul 2001, Roy T. Fielding wrote: > > The "correct" fix, as I see it, is to kill off the interprocess > > accept lock by removing the possibility of having other processes > > in a *threaded* MPM. -- justin > > That architecture was explored in detail by Netscape. It isn't reliable

RE: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded

On Sat, 14 Jul 2001, Sander Striker wrote: > The way I see it, each process has a single pool instance as the parent > for all the threads. Resetting or destroying that pool should effectively > kill all threads. What am I missing? how does a thread kill another thread? -dean

RE: Terminating threads in a process, WAS: RE: [PATCH] Problems withMPM threaded

On Sun, 15 Jul 2001, Sander Striker wrote: > Why are we so desperate in opting out the child-pool creation? > I don't really have problems with a child pool for each thread. Actually, > it will make the dynamic locking a lot easier to implement if it stays. all threads MUST have their own privat

Re: Terminiting threads in a process RE: [PATCH] Problems with MPMthreaded

On Sat, 14 Jul 2001, Aaron Bannert wrote: > On Sat, Jul 14, 2001 at 12:10:30PM -0700, [EMAIL PROTECTED] wrote: > > On Sat, 14 Jul 2001, Sander Striker wrote: > > > The way I see it, each process has a single pool instance as the parent > > > for all the threads. Resetting or destroying that pool

Re: [PATCH] Problems with MPM threaded

On Sat, 14 Jul 2001 [EMAIL PROTECTED] wrote: > Having multiple processes each with multiple threads provides for FAR > more robustness than just a single process with multiple threads. ya know, i'm not really convinced of the desirability of this explanation anymore. maybe the hypothetical bugg

Re: SMS as Pools Patch

t tack it on to the block that we have > just allocated. Dean Gaudet may have more explanation as to why we > do this, but the current pool code definitely does this. nope you've pretty much summed it up. it is a questionable optimisation though. > I'd like to see how it

RE: SMS usage patterns, hierarchies

On Wed, 11 Jul 2001, Sander Striker wrote: > > Thanks. If I'm reading the graphs right, they show > > that destruction of a leaf SMS with siblings is much > > more common than destruction or reset of a non-leaf > > SMS with children. That seems to reinforce the > > conclusion I drew from gprof d

Re: Hash tables and request headers Re: observations on fragmentation in SMS pools

On Tue, 10 Jul 2001, Brian Pane wrote: > 1. Add a 2nd create function for apr_hash_t that lets the caller > supply three callback functions: > - a hash function > - an equality-check function > - a concatenation function (if non-NULL, setting x=y followed by >x=y resu

Re: Hash tables and request headers Re: observations on fragmentationin SMS pools

On Tue, 10 Jul 2001, Brian Pane wrote: > 1. Add a 2nd create function for apr_hash_t that lets the caller > supply three callback functions: > - a hash function > - an equality-check function > - a concatenation function (if non-NULL, setting x=y followed by >x=y res

Re: APR Error Handling

On 9 Jul 2001, Ian Holsman wrote: > maybe there needs to be a method of registering error numbers/functions > so that apr_sterror knows that error 1230981 is from apr-util and would > call apr-util's function it registered to show the error message. hee! sorry, just thinking back to discussions

tables -> hash (Re: Observations on fragmentation in SMS pools)

On Mon, 9 Jul 2001, Roy T. Fielding wrote: > > Tables are in APR, because were originally moved from Apache to APR before > > APR-util existed. They should really move to apr-util. They should never > > be removed from Apache. Tables are useful because they garuantee a > > general order to the

data types on type of shm (Re: Observations on fragmentation in SMS pools)

On Mon, 9 Jul 2001, Luke Kenneth Casson Leighton wrote: > HOWEVER! supporting the data types that apr_pool_xxx() USES > is a different matter. shm can be at different memory locations in all processes. pointers don't work. you'd need to radically change the basic data types, which would affect

Re: multithreaded pools?

On Sun, 8 Jul 2001, Roy T. Fielding wrote: [clean_child_exit] > > It is only called when the child exits and not per-thread. I think the > threads are already dead by that point, or locked-up due to some fatal > error that is the reason why clean_child_exit is being called. when you say "the thr

Re: BSD Accept filters

On Tue, 10 Jul 2001, Dirk-Willem van Gulik wrote: > 0 Change the 'exit' when the sockopt fails for SO_ACCEPTFILTER > to a warning;. > 1 Leave as is; but provide an AcceptFilter on/off directive > to switch it off - if SO_ACCPETFILTER is defined. > 2.Have AcceptFitler on/

Re: Extraneous socket read?

On Sun, 8 Jul 2001, Brian Pane wrote: > So I guess the ideal algorithm for retrieving the initial request > from a client is: > > OS with working TCP_DEFER_ACCEPT or equivalent: select first, then read > OS without working TCP_DEFER_ACCEPT or equivalent: read first isn't it the other way a

Re: multithreaded pools?

On Sun, 8 Jul 2001, Roy T. Fielding wrote: [clean_child_exit] > > It is only called when the child exits and not per-thread. I think the > threads are already dead by that point, or locked-up due to some fatal > error that is the reason why clean_child_exit is being called. when you say "the th

Re: multithreaded pools?

On Sun, 8 Jul 2001, Roy T. Fielding wrote: > The last time I looked at the pool code it was bogus because clean_child_exit how can clean_child_exit ever hope to work in a multithreaded server without async notification? in particular, what happens when modules start creating their own thread poo

Re: multithreaded pools?

On Sun, 8 Jul 2001, Roy T. Fielding wrote: > The last time I looked at the pool code it was bogus because clean_child_exit how can clean_child_exit ever hope to work in a multithreaded server without async notification? in particular, what happens when modules start creating their own thread po

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Brian Pane wrote: > But Hoard is LGPL. :-( hey check this page out it tells me two things: - on linux with ptmalloc in glibc, the stock performance should be almost as good as with hoard - on solaris there is a stock

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Brian Pane wrote: > dean gaudet wrote: > > >On Sun, 8 Jul 2001, Ian Holsman wrote: > > > >>dean gaudet wrote: > >> > >>>it removes block_freelist and uses malloc/free for blocks. this is much > >>>less expensive than

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Ian Holsman wrote: > dean gaudet wrote: > > >it removes block_freelist and uses malloc/free for blocks. this is much > >less expensive than malloc/free on each allocation (amortization). > > If you can wait till monday, and you are interested, I'l

multithreaded pools?

so while hacking up that patch to eliminate the block_freelist i thought i could also get rid of the alloc_mutex entirely. but it appears that currently the pool code sort of supports multithreaded access to the same pool. i say "sort of" because cleanups don't support multithreaded access -- no

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Justin Erenkrantz wrote: > Also, I did try having the pools use malloc/free directly > (ALLOC_USE_MALLOC) and the performance was dreadful. At least on > Solaris. -- justin yes, ALLOC_USE_MALLOC is dreadful -- that's not what i meant. what i mean is something like the bel

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Jon Travis wrote: > I talked to rbb about this not too long ago, and he told me that you > did a lot of performance work, and that is why pools use their own > allocation scheme (8k blocks, freelists, etc.) instead of using a > total malloc() oriented scheme. yes and no. i ca

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Ben Laurie wrote: > Justin Erenkrantz wrote: > > Aaron pointed out that CLR (Cormen/Leiserson/Rivest for those that never > > took algorithms classes) has many memory allocation algorithms. I'd > > bet we could find one that would work better. -- justin > > At USENIX there wa

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Jon Travis wrote: > There is still all this tomfoolery with locking, though, which I think > would be nice to fix with different sized buckets in the freelist. > Stuff that the malloc in glibc does. I cringe at the thought of how > much overhead due to abstraction this whole p

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, dean gaudet wrote: > > > On Sun, 8 Jul 2001, Justin Erenkrantz wrote: > > > Yup. I've brought this up to Sander and David before, but this is how > > pools > > woah. no way really? > > that's not at all how it was in 1.3 or in ea

Re: Observations on fragmentation in SMS pools

On Sun, 8 Jul 2001, Justin Erenkrantz wrote: > Yup. I've brought this up to Sander and David before, but this is how > pools woah. no way really? that's not at all how it was in 1.3 or in early 2.0 ... in 2.0 as of uh a year ago say, there was one free list per process, and locks were used

Re: Observations on fragmentation in SMS pools

an ideal situation for free-lists (blocks of freed, but not free()d memory) is one per cpu. a less ideal situation is one per thread. an even less ideal situation is one per process (which requires locking). it's insane to have one per pool :) -dean

multithreaded pools?

so while hacking up that patch to eliminate the block_freelist i thought i could also get rid of the alloc_mutex entirely. but it appears that currently the pool code sort of supports multithreaded access to the same pool. i say "sort of" because cleanups don't support multithreaded access -- no

Re: Extraneous socket read?

On Sun, 8 Jul 2001, dean gaudet wrote: > On Sat, 7 Jul 2001, Bill Stoddard wrote: > > > Humm... If you use TCP_DEFER_ACCEPT, how to you handle clients > > connecting but not sending any bytes? > > i'm not sure what happens if they connect and close before the time

Re: Extraneous socket read?

On Sat, 7 Jul 2001, Bill Stoddard wrote: > > > On Sat, 7 Jul 2001, Brian Pane wrote: > > > > > If I'm reading the code right, there's one problem with this approach: the > > > APR_INCOMPLETE_READ flag doesn't get set until after the first > > > read on a socket, so the first read on a new conne

Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_trivial.c sms_private.h

On Sat, 7 Jul 2001 [EMAIL PROTECTED] wrote: > On Sat, 7 Jul 2001, Justin Erenkrantz wrote: > > > On Sat, Jul 07, 2001 at 12:26:32PM -, [EMAIL PROTECTED] wrote: > > > dreid 01/07/07 05:26:32 > > > > > > Modified:include apr_sms.h > > >memory/unix apr_sms.c apr_sms_t

Re: Extraneous socket read?

On Sat, 7 Jul 2001, Brian Pane wrote: > If I'm reading the code right, there's one problem with this approach: the > APR_INCOMPLETE_READ flag doesn't get set until after the first > read on a socket, so the first read on a new connection (the one that > usually > returns EAGAIN) doesn't get skippe

Re: Extraneous socket read?

On Mon, 2 Jul 2001, Brian Pane wrote: > >On Mon, 2 Jul 2001, Brian Pane wrote: > > > >>then it should be possible to eliminate a system call by not doing the > >>initial read before the select. > >> > Here's a patch that disables the read before the select, but only for > the HTTP client socket.

Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_trivial.c sms_private.h

On Sat, 7 Jul 2001, Aaron Bannert wrote: > > > I don't think there is any benefit to this. But, someone else might > > > be able to chime in and say why we need this functionality. -- justin > > > > how do you handle out of memory? > > > > palloc is not permitted to return NULL for performance r

Re: Shared Memory in APR

On Wed, 4 Jul 2001 [EMAIL PROTECTED] wrote: > On Wed, 4 Jul 2001, Ian Holsman wrote: > > > I'm looking at the shared memory functions (in unix), and am struggling > > to find out how one can attach to > > a shared memory segment already created by another process. > > Currently you can't, because

Re: cvs commit: apr/memory/unix apr_sms.c apr_sms_trivial.c sms_private.h

On Sat, 7 Jul 2001, Justin Erenkrantz wrote: > On Sat, Jul 07, 2001 at 12:26:32PM -, [EMAIL PROTECTED] wrote: > > dreid 01/07/07 05:26:32 > > > > Modified:include apr_sms.h > >memory/unix apr_sms.c apr_sms_trivial.c sms_private.h > > Log: > > Add the abort func

how to compile top of tree httpd-2.0 with top of tree apr?

i just did a fresh checkout of httpd-2.0, apr and apr-util and ran into one sms problem which i committed a fix for already... but now i'm getting this error: server/.libs/libmain.a(exports.o)(.data+0x234):/home/dean/ap2/httpd-2.0/server/exports.c: undefined reference to `apr_pool_num_bytes' serve

apr_is_option_set / apr_set_option / netmask

hi! why aren't basic bit manipulations being done directly? the function call overhead is enormous compared to the operations being performed. also... when i saw the field named netmask i kind of assumed it was a network address mask, which is usually what "netmask" refers to. why does it appea

TCP_DEFER_ACCEPT

i was digging around for info on TCP_DEFER_ACCEPT and found this claim in the thttpd mailing list archive: > Alexey Kuznestov mentioned to me that on SMP servers, this option may > not be desired as it creates a new contention point is this still the case? i haven't played with it yet, but i wa

Re: Extraneous socket read?

On Sat, 7 Jul 2001, Brian Pane wrote: > If I'm reading the code right, there's one problem with this approach: the > APR_INCOMPLETE_READ flag doesn't get set until after the first > read on a socket, so the first read on a new connection (the one that > usually > returns EAGAIN) doesn't get skipp

Re: Extraneous socket read?

On Mon, 2 Jul 2001, Brian Pane wrote: > >On Mon, 2 Jul 2001, Brian Pane wrote: > > > >>then it should be possible to eliminate a system call by not doing the > >>initial read before the select. > >> > Here's a patch that disables the read before the select, but only for > the HTTP client socket.

Re: [PATCH-concept] more dynamic configuration

On Fri, 6 Jul 2001, Harrie Hazewinkel wrote: > Attached is a patch that adds more dynamic configuration. > It places some of the MPM variables such as 'ap_max_daemons_limit', > 'ap_daemons_limit', 'ap_daemons_min_free' and 'ap_daemons_max_free' > in the scoreboard. -1. the concept is ok, but th

Re: Heap memory usage on Solaris 7

this is "expected behaviour" ... well, it may be a bug if you didn't see this before apache 1.3.20. a bunch of configuration info is duplicated for each . i forget all the exact details now, but what you want to be careful about are any configuration statements within the which modify the globa

perf tuning (RE: test harness for Apache)

On Thu, 5 Jul 2001 [EMAIL PROTECTED] wrote: > Does anyone know the best way/methods/tools to monitor web applications > running on Apache written in java, jsp and some CGI? Is server-status good? > Any hints on what to look for? Any books on performance or white papers? I > need to isolate per

Re: mod_file_cache performance

On 3 Jul 2001, Jeff Trawick wrote: > dean gaudet <[EMAIL PROTECTED]> writes: > > > there should be no reason to tweak TCP_NODELAY except at socket creation > > time. > > on at least some levels of Linux TCP_NODELAY and TCP_CORK are mutually > exclusive..

Re: Extraneous socket read?

On Mon, 2 Jul 2001, Brian Pane wrote: > Here's a patch that disables the read before the select, but only for > the HTTP client socket. Can somebody with a decent benchmark lab > test it out to see if the throughput change is significant? you can make some reasonable performance measurements wi

Re: Extraneous socket read?

an On Mon, 2 Jul 2001 [EMAIL PROTECTED] wrote: > On Mon, 2 Jul 2001, dean gaudet wrote: > > > On Mon, 2 Jul 2001, dean gaudet wrote: > > > > > (aie! is get{sock,peer}name really so expensive / used so much that > > > you need to keep userland copies?? that me

Re: mod_file_cache performance

On Mon, 2 Jul 2001, Sander van Zoest wrote: > Tony Finch work on this and his patch, > > to FreeBSD 5.0-CURRENT, makes TCP_NOPUSH behave in the manner of > Linux's TCP_CORK. woo! that mak

Re: Extraneous socket read?

On Mon, 2 Jul 2001, dean gaudet wrote: > (aie! is get{sock,peer}name really so expensive / used so much that > you need to keep userland copies?? that means you're paying for it > twice! once in the kernel, once in userland!) haha, *three* times! the third is in conn_rec :) -dean

Re: Extraneous socket read?

On Mon, 2 Jul 2001, dean gaudet wrote: > On Mon, 2 Jul 2001, Brian Pane wrote: > > > then it should be possible to eliminate a system call by not doing the > > initial read before the select. > > that sounds correct and a desirable change. i think the current behaviour

Re: Extraneous socket read?

On Mon, 2 Jul 2001, Brian Pane wrote: > then it should be possible to eliminate a system call by not doing the > initial read before the select. that sounds correct and a desirable change. i think the current behaviour goes all the way back to the first iol stuff i did, and was possibly just a

Re: mod_file_cache performance

On Mon, 2 Jul 2001, Brian Pane wrote: > dean gaudet wrote: > [...] > > >a mostly optimal syscall sequence for responses to a keep-alive > >connection on linux should look something like: > > > > sockfd = accept(); > > fcntl(sockfd, F_SETFL, O_NDEL

Re: mod_file_cache performance

On Mon, 2 Jul 2001, Bill Stoddard wrote: > For example, if you have three responses to serve pipelined, each with > three file handles, how do you make all the packets go out optimally > filled? TCP_CORK... > On Linux, can you TCP_CORK, call sendfile() x times then do an uncork > and have all

Re: mod_file_cache performance

incidentally -- there is an analogue to TCP_CORK on FreeBSD, i'm pretty sure it's TCP_NOPUSH. it's unfortunate that the two (almost identical) concepts developped independantly with different names. i don't know of any similar feature on other kernels. -dean On Mon, 2 J

Re: mod_file_cache performance

On Mon, 2 Jul 2001, Cliff Woolley wrote: > On Mon, 2 Jul 2001, dean gaudet wrote: > > > sendfile() is the best thing to use on linux (and probably everywhere else > > that has it). it doesn't require any virt->phys mappings to be created, > > and supports zero-c

Re: mod_file_cache performance

On Mon, 2 Jul 2001, Cliff Woolley wrote: > On Mon, 2 Jul 2001, Cliff Woolley wrote: > > > For keepalive requests, since this particular file is less than > > AP_MIN_BYTES_TO_WRITE in size, the core_output_filter will read in the > > file and hang on to it to try to send at the same time as the re

Re: mod_file_cache performance

On Mon, 2 Jul 2001, Cliff Woolley wrote: > static file local threaded: > > No keepalives Keepalives > -- > no cache 154.54 req/s 879.06 KB/s 2432.63 req/s 13924.84 KB/s > CacheFile 155.53 req/s 8

Re: mod_file_cache performance

i think). a handful of other drivers are still under development. anyhow, to see the difference with zero-copy enabled you'll probably need to study idle cpu (especially if it's only 100baseT). -dean On Mon, 2 Jul 2001, Cliff Woolley wrote: > On Mon, 2 Jul 2001, dean gaudet wrote: >

Re: mod_file_cache performance

another thing to study is strace output... with timestamps and syscall times. "strace -r -tt -T -p child_pid" should do it. you don't necessarily need to trace all the children. but you might as well trace a few, you could add "-ff -o outputprefix" to get your output into useable chunks. then

Re: mod_file_cache performance

is this across loopback? if so then it's useless for performance tuning/measurement. you gotta use a real network, and a beefy enough client to get any meaningful results. or is it a single 100baseT segment? if so then this is too little network to give meaningful results as well. unless you

Re: June 18th in logs

the 200 is meaningless. you can put whatever you want into the absuri and get back the default server. -dean On Thu, 28 Jun 2001, Cliff Woolley wrote: > On Thu, 28 Jun 2001, Tom Nichols wrote: > > > Got any idea why this would be in some of my Apache access-logs on > > different servers at aro

Re: [PATCH] mod_mime performance tweaks, revised

On Wed, 27 Jun 2001, Brian Pane wrote: > +/* Information to which an extension can be mapped > + */ > +typedef struct extension_info { > +char *forced_type;/* Additional AddTyped stuff */ > +char *encoding_type; /* Added with AddEncoding... */ > +char *lan

Re: Possible security enhancement to apache server

i did something similar ages ago... and i think manoj did some followon work to my patch. my idea was to use a wrapper much like innd uses, just to open the socket. if you look at and search for "pre_opened_socket", "permanent_listeners",

Re: directory_walk performance

On Mon, 25 Jun 2001, William A. Rowe, Jr. wrote: > One consideration, depending on module authorship, is if a module > author chooses to 'do something' in the directory merge operation, > relative to the request (uri, query elements, etc.) Does anyone know > of such a module? the merge function

Re: directory_walk performance

t; >already been made. Brian, I would suggest sending him e-mail on Monday so > >that you can take advantage of his work. He says it's not quite ready for > >public consumption yet, but I'm sure he'll send it if there is interest. > >BTW, this idea is great, I

Re: directory_walk performance

On Sat, 23 Jun 2001 [EMAIL PROTECTED] wrote: > On Sat, 23 Jun 2001, Bill Stoddard wrote: > > > > Just a heads up, because I know he's off-list this weekend. Will Rowe has > > > been looking at some of this stuff recently. He has basically re-worked > > > directory walk to take advantage of a lo

Re: directory_walk performance

that sounds good. it's just like constant-folding :) can you generalise it any? Alias and mod_userdir can add more constant factors in the path. -dean On Fri, 22 Jun 2001, Brian Pane wrote: > More fun with gprof... > directory_walk is one of the bigger consumers of user-mode CPU time in > th

Re: plz vote on tagging current CVS as APACHE_2_0_19

On Thu, 21 Jun 2001, Bill Stoddard wrote: > > This can be implemented just as well with the table implementation. The > > only thing you have to do is pad the scoreboard entry size to make it > > equal to one cache line. > > > And waste more storage? I am not a CPU designer...how big are cache l

Re: [PATCH] Add back -X functionality

when i did the MPM stuff i didn't want to try to figure out an interface for the command line arguments from the generic http_main to the MPM. doing the ONE_PROCESS thing was easy, and put the mpm into the same boat as the other modules... no access to the command line. between command lines, con

Re: Client receives TCP packets but does not ACK

On Tue, 19 Jun 2001, Jonathan Morton wrote: > > > > > Btw: can the aplication somehow ask the tcp/ip stack what was > >> >actualy acked? > >> >> (ie. how many bytes were acked). > >> > > >> >no, but it's not necessarily a useful number anyhow -- because it's > >> >possible that the remote

Re: Client receives TCP packets but does not ACK

On Mon, 18 Jun 2001, Jonathan Morton wrote: > > > Btw: can the aplication somehow ask the tcp/ip stack what was > >actualy acked? > >> (ie. how many bytes were acked). > > > >no, but it's not necessarily a useful number anyhow -- because it's > >possible that the remote end ACKd bytes but the

Re: Client receives TCP packets but does not ACK

On Mon, 18 Jun 2001, Jan Hudec wrote: > Btw: can the aplication somehow ask the tcp/ip stack what was actualy acked? > (ie. how many bytes were acked). no, but it's not necessarily a useful number anyhow -- because it's possible that the remote end ACKd bytes but the ACK never arrives. so you c

Re: Client receives TCP packets but does not ACK

On Sun, 17 Jun 2001, Dan Podeanu wrote: > Is there any logical reason why if, given fd is a connected, AF_INET, > SOCK_STREAM socket, and one does a write(fd, buffer, len); close(fd); > to the peer, over a rather slow network (read modem, satelite link, etc), > the data gets lost (the remote rece

Re: More migration of code from httpd to apr-util

On Fri, 8 Jun 2001, Justin Erenkrantz wrote: > On Fri, Jun 08, 2001 at 10:47:10AM -0700, dean gaudet wrote: > > > > > > On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote: > > > > > what i perhaps should recommend is that a series of independent > &g

Re: More migration of code from httpd to apr-util

On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote: > what i perhaps should recommend is that a series of independent > libraries be created. > > e.g. libaprhttputil (i know it's a bit long). why? we don't link against libcstdio libcstring libcsyscalls libcsortnsearch ... the point of a l

Re: Hooks for management reporting (was RE:New Hook)

On Fri, 8 Jun 2001, Greg Stein wrote: > As Ian pointed out, having mod_status directly read the scoreboard means > that we cannot experiment with different scoreboard designs. i've been saying the same thing since the beginning of MPM. the analogy between mod_status and /bin/ps is really valid.

Re: More migration of code from httpd to apr-util

On Fri, 8 Jun 2001, Justin Erenkrantz wrote: > On Fri, Jun 08, 2001 at 10:47:10AM -0700, dean gaudet wrote: > > > > > > On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote: > > > > > what i perhaps should recommend is that a series of independent > &g

Re: More migration of code from httpd to apr-util

On Fri, 8 Jun 2001, Luke Kenneth Casson Leighton wrote: > what i perhaps should recommend is that a series of independent > libraries be created. > > e.g. libaprhttputil (i know it's a bit long). why? we don't link against libcstdio libcstring libcsyscalls libcsortnsearch ... the point of a

Re: Break 2.4 VM in five easy steps

On Wed, 6 Jun 2001, Alexander Viro wrote: > On Wed, 6 Jun 2001, Sean Hunter wrote: > > > This is completely bogus. I am not saying that I can't afford the swap. > > What I am saying is that it is completely broken to require this amount > > of swap given the boundaries of efficient use. > > Funny

Re: Break 2.4 VM in five easy steps

On Wed, 6 Jun 2001, Dr S.M. Huen wrote: > If you can afford 4GB RAM, you certainly can afford 8GB swap. this is a completely crap argument. you should study the economics of managing a farm of thousands of machines some day. when you do this, you'll also learn to consider the power requirement

Re: [PATCH] Remove ap_parseHTTPdate

this would seem like an OK time to change the function name to something more in line with other names in ap/apr... such as ap_parse_http_date. (but include a comment indicating the old name somewhere so it's easy to find for those of us who grok foreign programs by doing recursive greps :) -dean

<    3   4   5   6   7   8   9   10   11   12   >