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.