Re: Performance analysis questions
Andrew Payne <payne@n8kei.tiac.net>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 12 May 1994 01:06:38 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199405112303.TAA06936@n8kei.tiac.net>
Errors-To: listmaster@www0.cern.ch
Reply-To: payne@n8kei.tiac.net
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: Andrew Payne <payne@n8kei.tiac.net>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Performance analysis questions
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
>2. Initial indications are that process startup time is the dominant
>factor. This suggests that a benchmark consisting of lots of little
>documents will be most telling; I expect that big documents will be
>bandwidth limited and not dependent on server performance (unless it's
>got a direct T3 interface).
I started hacking some instrumentation into NCSA's httpd to see where it
was spending time (I couldn't find a profiling tool that would work through
the fork(), though in retrospect it probably would have been easier to run
the server in single connection mode and throw out all of the startup
stuff). NOT counting the fork() time, I found the server spending about
20-30% of its time (wall and CPU) in the code that reads the request
headers. Code like this doesn't help (getline() in util.c):
if((ret = read(f,&s[i],1)) <= 0) {
Your mileage may vary.
>Any comments and suggestions are welcome, and I do plan to make the test
>suite available when finished, as well as a result summary. Thanks!
I too am interested in performance, and am interested in whatever you come
up with. I'm also interested in stories from sites that are suffering
scalability problems, if there are any to share.
Andrew Payne
Open Market, Inc.