98596 - loss of performance in networking modules

Status: VERIFIED INVALID

(Core :: Networking: HTTP, defect)

Description

[Tom Everingham]

Overview Description:  Networking changes may have caused loss of performance
according to JT's neckometer.

Steps to Reproduce:
1.)  Go to http://g.mcom.com/neckometer/

Comment 1

[Tom Everingham]

summary changes

Comment 2

[Tom Everingham]

..

Comment 3

[Tom Everingham]

reassigned to darin

Comment 4

[Darin Fisher]

tever: when did performance start to degrade?  following the neckometer link, i
don't see any upward trend in the graph.  am i missing something?

Comment 5

[Darin Fisher]

tever: i'm going to mark this as INVALID cuz i don't see the problem.

Comment 6

[Tom Everingham]

collision!

no, you are not missing anything.  The graph does not show the regression 
anymore.  It has scrolled out of view.  

There is a 'blames' link that would link to the code changes that might have 
caused the performance loss.  It appears to be invalid also probably because of 
the scrolling.   Neeti remembers that the code changes were on Sept 3, 4, or 5.  
You or Doug were making some changes with connections.  I will have to go in and 
look at the raw data files if that doesn't help.

Basically, the average time for the test has gone outside of a hardcoded window 
that JT put into his perl scripts.  Neckometer now sends me mail every 2 hours 
with the subject 'NECKO TRENDING UP'.  It is showing an average time of around 
153 milliseconds per run.  (This is an average of averages actually).  I believe 
it used to be around 145 so it is only a slight step up.  I will try to get a 
more specific date for you tomorrow or friday.

ps.  if you don't fix this I'm going to change the auto email link to darin :-)

Comment 7

[Darin Fisher]

tever: ok.. ic... well i suspect this is the result of my change to limit the
number of persistent http connections to only 2... believe it or not, the patch
actually helped overall page load times (as measured using ibench or cowtools).

but on a system dedicated to just pulling down documents off an http server it
is no surprise that we've lost some performance.

if this is indeed the cause of the problem, then i'd say that there's no need to
worry about it.  can you reset the upper bound on the neckometer to prevent
further emails?

Comment 8

[Tom Everingham]

That makes sense.  Yes I can center the boundary limits around the new avg. 
Will do it later this week though. 

Comment 9

[Tom Everingham]

ok, it turns out the drop in performance was only a few milliseconds.  I
adjusted the stable average in the linux neckometer from 151 to 153 ms.  (153.1
is the hand calculated average of the last 10 cycles)  

re-marking invalid 

Comment 10

[Tom Everingham]

verified