httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject Re: Some performance analysis of Apache 2.0 (Windows NT 4.0)
Date Thu, 07 Dec 2000 18:25:08 GMT
Bleh... Let's try something different...

Name                                      Self Time    #Calls

GetQueuedCompletionStatus     9.91 s        2534
WaitForSingleObject                 9.02 s        2535
FindFirstFileA                           2.13 s       10140
CreateFileW                             1.20 s         5070
 FindClose                                616.75ms   10140
free                                          454.90ms   55758
 _ap_byterange_filter                432.87ms    5069
 _ap_content_length_filter         419.15ms    5069
TransmitFile                              410.14ms    2535
CloseHandle                            351.85ms     5069
strlen                                        299.56ms   420810
malloc                                      265.18ms     48163
 _stricmp                                   244.27ms   375180
AcceptEx                                 141.15ms       2534
GetFileInformationByHandle     136.73ms       2535

----- Original Message -----
From: Bill Stoddard <bill@wstoddard.com>
To: <new-httpd@apache.org>
Sent: Thursday, December 07, 2000 11:38 AM
Subject: Some performance analysis of Apache 2.0 (Windows NT 4.0)


> Not sure how the column formatting will come though... The interesting
numbers
> are the 3rd column (SelfTime) and 5th columns (Number of calls to the
> function).  Basically two threads handled all the requests in this run (due
to
> the LIFO scheduling of threads dispatched off a Windows i/o completion port)
.
> Since my machine has a single CPU, I would expect large numbers in
> GetQueuedCompletionStatus and WaitForSingleObject.  As I suspected, that
> FindFirstFile call is killing us and I'd like to get rid of it (replace it
> with a more efficient call as in alpha5).
>
> I'm a bit suprised at the time spend in the byterange_filter and
> content_length_filters. Each filter seems to be called twice per request
(this
> run shows 2534 requests).  As expected, the additional mallocs and frees
> introduced with the filters is chewing up cycles. Not sure why we have more
> frees than mallocs though. Odd...
>

<snip>

> Bill
>


Mime
View raw message