loss of performance in networking modules

VERIFIED INVALID

Status

()

Core
Networking: HTTP
VERIFIED INVALID
17 years ago
17 years ago

People

(Reporter: Tom Everingham, Assigned: Darin Fisher)

Tracking

({perf})

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

17 years ago
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/
(Reporter)

Updated

17 years ago
Keywords: perf
(Reporter)

Comment 1

17 years ago
summary changes
Summary: performance drop → loss of performance in networking modules
(Reporter)

Comment 2

17 years ago
..
Assignee: neeti → darin
(Reporter)

Comment 3

17 years ago
reassigned to darin
(Assignee)

Comment 4

17 years ago
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?
(Assignee)

Comment 5

17 years ago
tever: i'm going to mark this as INVALID cuz i don't see the problem.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 6

17 years ago
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 :-)
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 7

17 years ago
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?
(Reporter)

Comment 8

17 years ago
That makes sense.  Yes I can center the boundary limits around the new avg. 
Will do it later this week though. 
(Reporter)

Comment 9

17 years ago
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 
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago17 years ago
Resolution: --- → INVALID
(Reporter)

Comment 10

17 years ago
verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.