httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: 1.3 pid table changes vs. uptime?
Date Wed, 24 Oct 2007 13:49:34 GMT
On 10/24/07, Jim Jagielski <jim@jagunet.com> wrote:
>
> On Oct 24, 2007, at 8:54 AM, Jim Jagielski wrote:
>
> >
> > On Oct 23, 2007, at 7:34 PM, Jeff Trawick wrote:
> >
> >>
> >> Alternative opinions?
> >
> > Alternative implementations are welcomed.
> >
>
> Certainly one trade-off would be speed over space; having
> pid_table an actual (C) array of pids.

current space before creating any child processes:

. a small bit of ap_table overhead
. an array of HARD_SERVER_LIMIT * sizeof(table_entry), where
table_entry is a couple of char *
. and more storage allocated/lost as we add entries to the table

future space before and after creating any child processes:

. an array of HARD_SERVER_LIMIT * sizeof(pid_t)

(though I see we pass pid around as an int so maybe sizeof(int) is a
more accurate way to describe it)

we just won the space trade-off

>                       When "setting" we would
> sequentially scan through that array for an "empty"
> space and tuck the pid in there; when removing we would
> scan though until we found our pid and unset it (0).

current lookup:
ap_snprintf(apid, sizeof(apid), "%d", pid);
for (i = 0; i < HARD_SERVER_LIMIT; i++) {
    if (!strcasecmp(pid_table[i].key, apid) {
        break;
    }
}

future lookup:

for (i = 0; i < HARD_SERVER_LIMIT; i++) {
    if (pid_table[i] == pid) {
        break;
    }
}

we just won the speed tradeoff

currently, when we actually modify the table to add or remove a pid,
we do this sort of logic:

	    else {		/* delete an extraneous element */
		for (j = i, k = i + 1; k < t->a.nelts; ++j, ++k) {
		    elts[j].key = elts[k].key;
		    elts[j].val = elts[k].val;
		}
		--t->a.nelts;
	    }

instead of simply setting the array element to 0

> I haven't profiled this so it actually might be better
> than the overhead of using ap_tables...
>
> Should I look at something like the above?

please ;)

(I need to get back to analyzing the proposed 1.3 proxy change to
ensure that differences between 1.3 utility routines and apr versions
don't make that a bad idea, as well as actually test it with more than
a cut-n-paste of the time string example in the asctime man page)

Mime
View raw message