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/
Summary: performance drop → loss of performance in networking modules
Assignee: neeti → darin
reassigned to darin
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?
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
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 → ---
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?
That makes sense. Yes I can center the boundary limits around the new avg. Will do it later this week though.
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 ago → 17 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.