You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ed Korthof <ed...@organic.com> on 1997/01/31 17:53:21 UTC
ack re: [PATCH] performance improvement
hold on the last patch.. the stuff to try to catch an error (via
r->server) seems to cause problems.n
-- Ed Korthof | Web Server Engineer --
-- ed@organic.com | Organic Online, Inc --
-- (415) 278-5676 | Fax: (415) 284-6891 --
Re: ack re: [PATCH] performance improvement
Posted by Marc Slemko <ma...@znep.com>.
On Sat, 1 Feb 1997, Ed Korthof wrote:
> I'm not too surprised about the minimal improvements from changing the
> tests. Really, we need a better method to parse the file...
>
> I don't know the frequency with which GET_CHAR is used in different
> sections, but find_string does seem to be the most likely resource hog.
>
> Could you send your whole patch? Ugly doesn't bother me too much, since
> I'd expect primary development to shift from this code base to something
> new (for Apache 2.0) once we finish 1.2. Besides, what's there now is
> pretty ugly & somewhat inefficient...
I modified the way I did it slightly since my first experiment.
With no includes:
1.75 real 0.03 user 0.62 sys
With includes as the current tree has:
7.62 real 0.02 user 0.50 sys
With includes after this patch:
4.21 real 0.01 user 0.50 sys
These numbers are on a
echo "GET /~marcs/i3.html" | time nc -n -vv 127.0.0.1 80 > /dev/null
Where i3.html is ~4 megs long and contains only one SSI directive at the
start, with the rest being plain text. My test methods aren't overly
accurate, but they do demonstrate the general trend. I think something
similar to the below (but cleaned up a bit) may be worthwhile adding.
Index: mod_include.c
===================================================================
RCS file: /export/home/cvs/apache/src/mod_include.c,v
retrieving revision 1.21
diff -c -r1.21 mod_include.c
*** mod_include.c 1997/01/20 04:28:13 1.21
--- mod_include.c 1997/02/02 04:42:01
***************
*** 113,122 ****
--- 113,136 ----
}
}
+
+ #define PUT_CH(x) \
+ { \
+ outbuf[outind++] = x; \
+ if (outind == 5000) { rwrite(outbuf, 5000, r); outind = 0; } \
+ }
+
+ #define FLUSH_CH() \
+ { \
+ rwrite(outbuf, outind, r); \
+ outind = 0; \
+ }
+
#define GET_CHAR(f,c,r,p) \
{ \
int i = getc(f); \
if(feof(f) || ferror(f) || (i == -1)) { \
+ FLUSH_CH(); \
pfclose(p,f); \
return r; \
} \
***************
*** 129,156 ****
* matter much, but this is an inner loop...
*/
int find_string(FILE *in,char *str, request_rec *r, int printing) {
int x,l=strlen(str),p;
char c;
p=0;
while(1) {
GET_CHAR(in,c,1,r->pool);
if(c == str[p]) {
! if((++p) == l)
return 0;
}
else {
if (printing) {
for(x=0;x<p;x++) {
! rputc(str[x],r);
}
! rputc(c,r);
}
p=0;
}
}
}
/*
* decodes a string containing html entities or numeric character references.
--- 143,178 ----
* matter much, but this is an inner loop...
*/
+
int find_string(FILE *in,char *str, request_rec *r, int printing) {
int x,l=strlen(str),p;
char c;
+ char outbuf[5000];
+ int outind = 0;
p=0;
while(1) {
GET_CHAR(in,c,1,r->pool);
if(c == str[p]) {
! if((++p) == l) {
! FLUSH_CH();
return 0;
+ }
}
else {
if (printing) {
for(x=0;x<p;x++) {
! PUT_CH(str[x]);
}
! PUT_CH(c);
}
p=0;
}
}
}
+
+ #undef FLUSH_CH
+ #define FLUSH_CH()
/*
* decodes a string containing html entities or numeric character references.
Re: ack re: [PATCH] performance improvement
Posted by Ed Korthof <ed...@organic.com>.
I'm not too surprised about the minimal improvements from changing the
tests. Really, we need a better method to parse the file...
I don't know the frequency with which GET_CHAR is used in different
sections, but find_string does seem to be the most likely resource hog.
Could you send your whole patch? Ugly doesn't bother me too much, since
I'd expect primary development to shift from this code base to something
new (for Apache 2.0) once we finish 1.2. Besides, what's there now is
pretty ugly & somewhat inefficient...
-- Ed Korthof | Web Server Engineer --
-- ed@organic.com | Organic Online, Inc --
-- (415) 278-5676 | Fax: (415) 284-6891 --
On Sat, 1 Feb 1997, Marc Slemko wrote:
> On Fri, 31 Jan 1997, Ed Korthof wrote:
>
> > On Jan 31, 9:58pm, Rob Hartill wrote:
> > > > Yes, I realized that. <blush> Well, without that, the patch appears to
> > > > work fine --
> > >
> > > did you measure any performance gain ?. Every little helps. Was it too
> > > little to notice though ?
> >
> > Not yet -- I'll try this weekend or early next week. We'll also be switching
> > to the most recent beta, and will see if that leads to any performance
> > improvements (I'll have a good idea if there was a net performance gain, but
> > it'll be hard to identify which components contributed).
>
> I hacked GET_CHAR in mod_include to have its own buffer and pull in data
> in chunks of 5000 bytes; ie. return a byte from the buffer if the buffer
> isn't empty, get more if it is. This resulted in a very minimal
> performance improvement. The removal of the feof and ferror checks had a
> similarily trivial improvement. A large file (2-15 megs in size) with no
> parsing expansions in it still gets sent at ~1/3rd the speed of a
> non-parsed file, regardless of which of the above I tried. I don't think
> input buffering is the biggest problem, at least on FreeBSD.
>
> By adding a rputc define to mod_include that did simple output buffering
> in blocks of 5000 bytes (well, 1k blocks did around the same thing) and
> then calling rwrite I was able to boost the speed so it was 2/3rds
> the speed, again with no actual directives being parsed. This
> requires several other modifications to work properly. For one,
> all output needs to use the same buffering or things (the few things
> that aren't sent with rputc) will get put in the wrong order. The
> second thing is that it needs to flush the buffer before exit.
> Neither are overly complicated.
>
> My hack to mod_include to simple output buffering:
>
> #define rputc(c,r) \
> { \
> if (buffered == 5000) { rwrite(outbuf, 5000, r); buffered = 0; } \
> outbuf[buffered++] = c; \
> }
>
> ...with buffered and outbuf being global variables.
>
> Comments? Ugly, but...
>
Re: ack re: [PATCH] performance improvement
Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 1 Feb 1997, Marc Slemko wrote:
> ie. it could be better, but there are things an order of magnitude
> worse all over the server.
I'm placing my bets on handlers invoked too frequently. While
investigating the mod_usertrack problem that other user reported I decided
to try this:
CustomLog logs/cookie_log "%{Cookie}n %<{Cookie}n %>{Cookie}n"
And I saw lines like:
bluelark12940854859039481 bluelark12940854859039274 bluelark12940854859039481
Indicating that mod_usertrack is generating cookies for all the subrequests
too.
I've seen this a lot when writing my own modules. Is there a proper
way to do something once?
Dean
Re: ack re: [PATCH] performance improvement
Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 1 Feb 1997, Marc Slemko wrote:
> Trouble is we don't have this in main memory to jump through anyway.
Well the compiler textbook answer (i.e. dragon book) to this problem is a
buffer pair with sentinels (the sentinel reduces the comparisons in the
inner-loop). But mmap() or fread() of the entire file is way preferable
in this case.
> Are you suggesting seeking back and forth through the file? You still
> have to copy it into memory, may as well do the copy and compare at the
> same time.
I wasn't picturing seeking, I just didn't state that I expected sufficient
chunks of the input to be in memory.
memcpy is typically implemented using 32-bit (or 64-bit) copies plus
round-off to deal with straggling bytes. It's a lot faster to copy
without comparing.
Dean
P.S. Um, you wouldn't believe the amount of energy that went into an
optimized memcpy/memset for the Pentium when WATCOM first got access to a
simulator years ago... Intel had this set of benchmarks that vendors had
to do "well" on before their compilers could be stamped "official" or
something like that. One of them was a really poor sieve that was small
enough that the initial for() loop to zero the sieve was significant in
the profile. Our compiler would detect the loop (a general case of
similar loops) and mutate it into a memset(). Our memset() used every
last trick we could squeeze out of Appendix H plus a few more the
simulator hinted at... resulting in something that can quite easily
overrun the memory bandwidth available. At any rate the moral of this
is... use memcpy() et al whenever possible 'cause some intern probably
slaved away trying a million mutations of it until he/she got it down to a
minimum of cycles.
Re: ack re: [PATCH] performance improvement
Posted by Marc Slemko <ma...@znep.com>.
On Sat, 1 Feb 1997, Dean Gaudet wrote:
> Since GET_CHAR just does a getc() and getc() is usually a macro that reads
> from a buffer... you won't gain a lot by adding another buffer.
That's what I figured, however there is a litt more than that going on in
FreeBSD. Worth trying. On the same token, feof and ferror are macros on
many platforms; on FreeBSD they just:
/usr/include/stdio.h:#define __sfeof(p) (((p)->_flags & __SEOF) != 0)
/usr/include/stdio.h:#define __sferror(p) (((p)->_flags & __SERR) != 0)
/usr/include/stdio.h:#define feof(p) __sfeof(p)
/usr/include/stdio.h:#define ferror(p) __sferror(p)
I think it is still worth getting rid of them, though.
>
> One thing you can do is optimize find_string(). Just eye-balling the code
> it looks like find_string( "<!--#" ) is a bottleneck -- using a better
> string matching algorithm you only have to peek at every 5th character to
> see if you're in the middle of a START_SEQUENCE. The END_SEQUENCE doesn't
> win as much, but it's still probably worth doing it (skip of 3 possible).
> What's that algorithm called... Morris-Knuth-Pratt?
Trouble is we don't have this in main memory to jump through anyway. If
it were mmap()ed, this could be a definite win; then no copying at all
and we should even be able to call bwrite() without copying them out of
the mmap()ed memory. I'm not sure this is any significant bottleneck
though; ie. it could be better, but there are things an order of magnitude
worse all over the server.
>
> If you're just peeking at the characters, you can avoid copying until
> you've found the tail of a "plain text" section and then do a rwrite() for
> the entire range, buffering happens beneath rwrite(), and you'll probably
> pick up enough data in plain text sections to get most of the benefit of
> your buffering approach.
Are you suggesting seeking back and forth through the file? You still
have to copy it into memory, may as well do the copy and compare at the
same time.
A cleaner way to do my hack would be to do essentially the same thing, but
only do it in find_string(). This means you can explicitly flush before
calling anything else, so all you need are two more macros and a couple of
lines in find_string. Hmm.
>
> (Hotwired's hacked up mod_include includes output buffering, and a totally
> incompatible condtional syntax, and find_string() for START_SEQUENCE was
> written sort of how I describe above, minus the 5 character skip. It's
> about 1/3rd the speed of the default_handler() based on an entire day of
> cpu timing data.)
>
> Dean
>
> On Sat, 1 Feb 1997, Marc Slemko wrote:
>
> > On Fri, 31 Jan 1997, Ed Korthof wrote:
> >
> > > On Jan 31, 9:58pm, Rob Hartill wrote:
> > > > > Yes, I realized that. <blush> Well, without that, the patch appears to
> > > > > work fine --
> > > >
> > > > did you measure any performance gain ?. Every little helps. Was it too
> > > > little to notice though ?
> > >
> > > Not yet -- I'll try this weekend or early next week. We'll also be switching
> > > to the most recent beta, and will see if that leads to any performance
> > > improvements (I'll have a good idea if there was a net performance gain, but
> > > it'll be hard to identify which components contributed).
> >
> > I hacked GET_CHAR in mod_include to have its own buffer and pull in data
> > in chunks of 5000 bytes; ie. return a byte from the buffer if the buffer
> > isn't empty, get more if it is. This resulted in a very minimal
> > performance improvement. The removal of the feof and ferror checks had a
> > similarily trivial improvement. A large file (2-15 megs in size) with no
> > parsing expansions in it still gets sent at ~1/3rd the speed of a
> > non-parsed file, regardless of which of the above I tried. I don't think
> > input buffering is the biggest problem, at least on FreeBSD.
> >
> > By adding a rputc define to mod_include that did simple output buffering
> > in blocks of 5000 bytes (well, 1k blocks did around the same thing) and
> > then calling rwrite I was able to boost the speed so it was 2/3rds
> > the speed, again with no actual directives being parsed. This
> > requires several other modifications to work properly. For one,
> > all output needs to use the same buffering or things (the few things
> > that aren't sent with rputc) will get put in the wrong order. The
> > second thing is that it needs to flush the buffer before exit.
> > Neither are overly complicated.
> >
> > My hack to mod_include to simple output buffering:
> >
> > #define rputc(c,r) \
> > { \
> > if (buffered == 5000) { rwrite(outbuf, 5000, r); buffered = 0; } \
> > outbuf[buffered++] = c; \
> > }
> >
> > ...with buffered and outbuf being global variables.
> >
> > Comments? Ugly, but...
> >
> >
>
Re: ack re: [PATCH] performance improvement
Posted by Dean Gaudet <dg...@arctic.org>.
Since GET_CHAR just does a getc() and getc() is usually a macro that reads
from a buffer... you won't gain a lot by adding another buffer.
One thing you can do is optimize find_string(). Just eye-balling the code
it looks like find_string( "<!--#" ) is a bottleneck -- using a better
string matching algorithm you only have to peek at every 5th character to
see if you're in the middle of a START_SEQUENCE. The END_SEQUENCE doesn't
win as much, but it's still probably worth doing it (skip of 3 possible).
What's that algorithm called... Morris-Knuth-Pratt?
If you're just peeking at the characters, you can avoid copying until
you've found the tail of a "plain text" section and then do a rwrite() for
the entire range, buffering happens beneath rwrite(), and you'll probably
pick up enough data in plain text sections to get most of the benefit of
your buffering approach.
(Hotwired's hacked up mod_include includes output buffering, and a totally
incompatible condtional syntax, and find_string() for START_SEQUENCE was
written sort of how I describe above, minus the 5 character skip. It's
about 1/3rd the speed of the default_handler() based on an entire day of
cpu timing data.)
Dean
On Sat, 1 Feb 1997, Marc Slemko wrote:
> On Fri, 31 Jan 1997, Ed Korthof wrote:
>
> > On Jan 31, 9:58pm, Rob Hartill wrote:
> > > > Yes, I realized that. <blush> Well, without that, the patch appears to
> > > > work fine --
> > >
> > > did you measure any performance gain ?. Every little helps. Was it too
> > > little to notice though ?
> >
> > Not yet -- I'll try this weekend or early next week. We'll also be switching
> > to the most recent beta, and will see if that leads to any performance
> > improvements (I'll have a good idea if there was a net performance gain, but
> > it'll be hard to identify which components contributed).
>
> I hacked GET_CHAR in mod_include to have its own buffer and pull in data
> in chunks of 5000 bytes; ie. return a byte from the buffer if the buffer
> isn't empty, get more if it is. This resulted in a very minimal
> performance improvement. The removal of the feof and ferror checks had a
> similarily trivial improvement. A large file (2-15 megs in size) with no
> parsing expansions in it still gets sent at ~1/3rd the speed of a
> non-parsed file, regardless of which of the above I tried. I don't think
> input buffering is the biggest problem, at least on FreeBSD.
>
> By adding a rputc define to mod_include that did simple output buffering
> in blocks of 5000 bytes (well, 1k blocks did around the same thing) and
> then calling rwrite I was able to boost the speed so it was 2/3rds
> the speed, again with no actual directives being parsed. This
> requires several other modifications to work properly. For one,
> all output needs to use the same buffering or things (the few things
> that aren't sent with rputc) will get put in the wrong order. The
> second thing is that it needs to flush the buffer before exit.
> Neither are overly complicated.
>
> My hack to mod_include to simple output buffering:
>
> #define rputc(c,r) \
> { \
> if (buffered == 5000) { rwrite(outbuf, 5000, r); buffered = 0; } \
> outbuf[buffered++] = c; \
> }
>
> ...with buffered and outbuf being global variables.
>
> Comments? Ugly, but...
>
>
Re: ack re: [PATCH] performance improvement
Posted by Marc Slemko <ma...@znep.com>.
On Fri, 31 Jan 1997, Ed Korthof wrote:
> On Jan 31, 9:58pm, Rob Hartill wrote:
> > > Yes, I realized that. <blush> Well, without that, the patch appears to
> > > work fine --
> >
> > did you measure any performance gain ?. Every little helps. Was it too
> > little to notice though ?
>
> Not yet -- I'll try this weekend or early next week. We'll also be switching
> to the most recent beta, and will see if that leads to any performance
> improvements (I'll have a good idea if there was a net performance gain, but
> it'll be hard to identify which components contributed).
I hacked GET_CHAR in mod_include to have its own buffer and pull in data
in chunks of 5000 bytes; ie. return a byte from the buffer if the buffer
isn't empty, get more if it is. This resulted in a very minimal
performance improvement. The removal of the feof and ferror checks had a
similarily trivial improvement. A large file (2-15 megs in size) with no
parsing expansions in it still gets sent at ~1/3rd the speed of a
non-parsed file, regardless of which of the above I tried. I don't think
input buffering is the biggest problem, at least on FreeBSD.
By adding a rputc define to mod_include that did simple output buffering
in blocks of 5000 bytes (well, 1k blocks did around the same thing) and
then calling rwrite I was able to boost the speed so it was 2/3rds
the speed, again with no actual directives being parsed. This
requires several other modifications to work properly. For one,
all output needs to use the same buffering or things (the few things
that aren't sent with rputc) will get put in the wrong order. The
second thing is that it needs to flush the buffer before exit.
Neither are overly complicated.
My hack to mod_include to simple output buffering:
#define rputc(c,r) \
{ \
if (buffered == 5000) { rwrite(outbuf, 5000, r); buffered = 0; } \
outbuf[buffered++] = c; \
}
...with buffered and outbuf being global variables.
Comments? Ugly, but...
Re: ack re: [PATCH] performance improvement
Posted by Ed Korthof <ed...@organic.com>.
On Jan 31, 9:58pm, Rob Hartill wrote:
> > Yes, I realized that. <blush> Well, without that, the patch appears to
> > work fine --
>
> did you measure any performance gain ?. Every little helps. Was it too
> little to notice though ?
Not yet -- I'll try this weekend or early next week. We'll also be switching
to the most recent beta, and will see if that leads to any performance
improvements (I'll have a good idea if there was a net performance gain, but
it'll be hard to identify which components contributed).
> There's certainly scope in some (many?) modules to improve on efficiency
> by examining when module entry point are being called unecessarily, well
> not 'uneecessarily' but, the modules are doing pointless work because
> they're being called at times when they have nothing worthwhile to contribute
> to the request. You can see an example of that with the patch to
> mod_expires that has yet to be committed. mod_browser also repeats itself
> multiple times per request under certain circumstances (e.g. with
> DirectoryIndex I believe).
Hmm... I'll look into this some. Seems reasonable to try to reduce repeated
calls to modules.
> Anyone know if mod_log_config (which is now the default) is costing any
> extra time ?
>
> Are we going to delay 1.2 even further to take more efficiency patches ?
> Who's carrying the 'release manager' ball today ?
Well, I want to try out the most recent beta -- if it's significantly more
efficient than previous versions, then I'll be satisfied; but if reports of the
relative efficient v. 1.1 are still true, then I'd say we should.
IMO, we should be able to get more than 100 requests per second on a 200+ mHz
DEC alpha running OSF/1 -- and we're currently maxing somewhere between 60 and
70. (Basically 1.2b2 code base, but not just a test-bed system -- many pages,
including compiled CGIs and SSIs.)
--
-- Ed Korthof | Web Server Engineer --
-- ed@organic.com | Organic Online, Inc --
-- (415) 278-5676 | Fax: (415) 284-6891 --
Re: ack re: [PATCH] performance improvement
Posted by Marc Slemko <ma...@znep.com>.
On Fri, 31 Jan 1997, Dean Gaudet wrote:
> BTW, if anyone wants to test a *BSD or other system to see what writev()
> does I've included a test program. Run it with the ip addr of a webserver
> and port 80 as args, and it fires 300 'x's at the port in 3 100 byte hunks
> using writev(). Watch the wire with tcpdump to see how many data packets
> are involved.
FYI, from BSD to BSD I get:
08:28:02.394944 darkly.worldgate.com.1483 > valis.worldgate.com.1234: S 1126912000:1126912000(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 281357 2466181682,opt-62:0600440000004a> (DF)
08:28:02.395582 valis.worldgate.com.1234 > darkly.worldgate.com.1483: S 3516878142:3516878142(0) ack 1126912001 win 8760 <mss 1460,nop,wscale 0,nop,nop,timestamp 265482 2466181682>
08:28:02.396036 darkly.worldgate.com.1483 > valis.worldgate.com.1234: . ack 1 win 17376 <nop,nop,timestamp 278200 278495> (DF)
08:28:02.396632 darkly.worldgate.com.1483 > valis.worldgate.com.1234: P 1:301(300) ack 1 win 17376 <nop,nop,timestamp 278200 278495> (DF)
08:28:02.397787 darkly.worldgate.com.1483 > valis.worldgate.com.1234: F 301:301(0) ack 1 win 17376 <nop,nop,timestamp 278200 278495> (DF)
08:28:02.398232 valis.worldgate.com.1234 > darkly.worldgate.com.1483: . ack 302 win 8460 <nop,nop,timestamp 278495 278200>
08:28:02.403382 valis.worldgate.com.1234 > darkly.worldgate.com.1483: F 1:1(0) ack 302 win 8760 <nop,nop,timestamp 278495 278200>
08:28:02.403849 darkly.worldgate.com.1483 > valis.worldgate.com.1234: . ack 2 win 17376 <nop,nop,timestamp 278200 278495> (DF)
Looks fine.
Re: ack re: [PATCH] performance improvement
Posted by Dean Gaudet <dg...@arctic.org>.
On Fri, 31 Jan 1997, Rob Hartill wrote:
> Are we going to delay 1.2 even further to take more efficiency patches ?
> Who's carrying the 'release manager' ball today ?
Speaking of efficiency patches. I worked on the chunked encoding patch
only to end up at a point where I would possibly have to copy around huge
chunks of ram (bwrite with nbytes > bufsiz) just to avoid extra write()
calls.
After experimenting a bit more with linux I discovered that if you do a
writev() with two elements it writes two packets, but it only writes two
packets if you do writev() with three. I was communicating with Alan Cox
about it and I'm not sure if he considers it a bug. I do consider it a
performance problem, but it's up to the linux folk to decide to fix it.
Solaris and IRIX write a single packet on the wire for a writev()
(assuming it fits). I'm guessing *BSD does as well.
BTW, if anyone wants to test a *BSD or other system to see what writev()
does I've included a test program. Run it with the ip addr of a webserver
and port 80 as args, and it fires 300 'x's at the port in 3 100 byte hunks
using writev(). Watch the wire with tcpdump to see how many data packets
are involved.
So, I am probably going to roll a patch that does those large writes by
using writev() to form the header+chunk+trailer, and otherwise does the
buffer manipulation I've talked about before (which will make more sense
when you see it). It will definately complicate buff.c, but I'm
abstracting it as much as possible.
Dean
Re: ack re: [PATCH] performance improvement
Posted by Rob Hartill <ro...@imdb.com>.
On Fri, 31 Jan 1997, Ed Korthof wrote:
> Yes, I realized that. <blush> Well, without that, the patch appears to
> work fine --
did you measure any performance gain ?. Every little helps. Was it too
little to notice though ?
> I'm going to be doing more tests today, since we need to
> improve performance, and this seems one place to start. Anyway, the
> attached patch has less effective error reporting, but I can't get
> log_printf working w/ this macro, so...
There's certainly scope in some (many?) modules to improve on efficiency
by examining when module entry point are being called unecessarily, well
not 'uneecessarily' but, the modules are doing pointless work because
they're being called at times when they have nothing worthwhile to contribute
to the request. You can see an example of that with the patch to
mod_expires that has yet to be committed. mod_browser also repeats itself
multiple times per request under certain circumstances (e.g. with
DirectoryIndex I believe).
Anyone know if mod_log_config (which is now the default) is costing any
extra time ?
Are we going to delay 1.2 even further to take more efficiency patches ?
Who's carrying the 'release manager' ball today ?
rob
Re: ack re: [PATCH] performance improvement
Posted by Rob Hartill <ro...@imdb.com>.
On Sat, 1 Feb 1997, Dean Gaudet wrote:
> +1
>
> On Fri, 31 Jan 1997, Ed Korthof wrote:
>
> > Yes, I realized that. <blush> Well, without that, the patch appears to
> > work fine -- I'm going to be doing more tests today, since we need to
> > improve performance, and this seems one place to start. Anyway, the
> > attached patch has less effective error reporting, but I can't get
> > log_printf working w/ this macro, so...
> >
> > -- Ed Korthof | Web Server Engineer --
> > -- ed@organic.com | Organic Online, Inc --
> > -- (415) 278-5676 | Fax: (415) 284-6891 --
> >
> > On Fri, 31 Jan 1997, Rob Hartill wrote:
> >
> > > On Fri, 31 Jan 1997, Ed Korthof wrote:
> > >
> > > > hold on the last patch.. the stuff to try to catch an error (via
> > > > r->server) seems to cause problems.n
> > >
> > > r != the request record in this case. It's the 'return' value.
> >
> >
>
>
>
_______________________________________________________________________
Rob Hartill. Internet Movie Database Ltd. http://www.imdb.com/
Re: ack re: [PATCH] performance improvement
Posted by Dean Gaudet <dg...@arctic.org>.
On Sat, 1 Feb 1997, Rob Hartill wrote:
> On Sat, 1 Feb 1997, Dean Gaudet wrote:
>
> > +1
> >
> > On Fri, 31 Jan 1997, Ed Korthof wrote:
> >
> > > Yes, I realized that. <blush> Well, without that, the patch appears to
> > > work fine -- I'm going to be doing more tests today, since we need to
> > > improve performance, and this seems one place to start. Anyway, the
> > > attached patch has less effective error reporting, but I can't get
> > > log_printf working w/ this macro, so...
>
> Can someone resend the fixed patch. I missed it somehow.
*** mod_include.c Fri Jan 31 09:53:20 1997
--- mod_include.c.orig Fri Jan 31 09:45:28 1997
***************
*** 116,125 ****
#define GET_CHAR(f,c,r,p) \
{ \
int i = getc(f); \
! if (i == EOF) { /* either EOF or error--needs error handling if latter */ \
! if (ferror(f)) \
! fprintf(stderr, \
! "encountered error in GET_CHAR macro, mod_include.\n"); \
pfclose(p,f); \
return r; \
} \
--- 116,122 ----
#define GET_CHAR(f,c,r,p) \
{ \
int i = getc(f); \
! if(feof(f) || ferror(f) || (i == -1)) { \
pfclose(p,f); \
return r; \
} \
Re: ack re: [PATCH] performance improvement
Posted by Rob Hartill <ro...@imdb.com>.
On Sat, 1 Feb 1997, Dean Gaudet wrote:
> +1
>
> On Fri, 31 Jan 1997, Ed Korthof wrote:
>
> > Yes, I realized that. <blush> Well, without that, the patch appears to
> > work fine -- I'm going to be doing more tests today, since we need to
> > improve performance, and this seems one place to start. Anyway, the
> > attached patch has less effective error reporting, but I can't get
> > log_printf working w/ this macro, so...
Can someone resend the fixed patch. I missed it somehow.
thanks
Re: ack re: [PATCH] performance improvement
Posted by Dean Gaudet <dg...@arctic.org>.
+1
On Fri, 31 Jan 1997, Ed Korthof wrote:
> Yes, I realized that. <blush> Well, without that, the patch appears to
> work fine -- I'm going to be doing more tests today, since we need to
> improve performance, and this seems one place to start. Anyway, the
> attached patch has less effective error reporting, but I can't get
> log_printf working w/ this macro, so...
>
> -- Ed Korthof | Web Server Engineer --
> -- ed@organic.com | Organic Online, Inc --
> -- (415) 278-5676 | Fax: (415) 284-6891 --
>
> On Fri, 31 Jan 1997, Rob Hartill wrote:
>
> > On Fri, 31 Jan 1997, Ed Korthof wrote:
> >
> > > hold on the last patch.. the stuff to try to catch an error (via
> > > r->server) seems to cause problems.n
> >
> > r != the request record in this case. It's the 'return' value.
>
>
Re: ack re: [PATCH] performance improvement
Posted by Ed Korthof <ed...@organic.com>.
Yes, I realized that. <blush> Well, without that, the patch appears to
work fine -- I'm going to be doing more tests today, since we need to
improve performance, and this seems one place to start. Anyway, the
attached patch has less effective error reporting, but I can't get
log_printf working w/ this macro, so...
-- Ed Korthof | Web Server Engineer --
-- ed@organic.com | Organic Online, Inc --
-- (415) 278-5676 | Fax: (415) 284-6891 --
On Fri, 31 Jan 1997, Rob Hartill wrote:
> On Fri, 31 Jan 1997, Ed Korthof wrote:
>
> > hold on the last patch.. the stuff to try to catch an error (via
> > r->server) seems to cause problems.n
>
> r != the request record in this case. It's the 'return' value.
Re: ack re: [PATCH] performance improvement
Posted by Rob Hartill <ro...@imdb.com>.
On Fri, 31 Jan 1997, Ed Korthof wrote:
> hold on the last patch.. the stuff to try to catch an error (via
> r->server) seems to cause problems.n
r != the request record in this case. It's the 'return' value.