Bug 522766 - Implement timing collection for the Node server and endpoints
Summary: Implement timing collection for the Node server and endpoints
Status: RESOLVED FIXED
Alias: None
Product: Orion (Archived)
Classification: ECD
Component: Node (show other bugs)
Version: 15.0   Edit
Hardware: PC Mac OS X
: P2 major (vote)
Target Milestone: 17.0   Edit
Assignee: Michael Rennie CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2017-09-25 14:59 EDT by Michael Rennie CLA
Modified: 2017-10-05 09:11 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Rennie CLA 2017-09-25 14:59:10 EDT
We should use expressjs' response-time library to collect timings for how long the server is taking to process requests.

As a start, we should collect:
1. the total time the server takes to process a given request
2. the total time it takes for any given endpoint / middleware to process a request.
Comment 1 Eclipse Genie CLA 2017-09-25 15:32:46 EDT
GitHub Pull Request 198 created by [mrennie]
https://github.com/eclipse/orion.client/pull/198
Comment 2 Michael Rennie CLA 2017-09-25 15:39:20 EDT
The pull request adds in timing collection to the server and endpoints. In the case of the /gitapi endpoint, there is also timing collection in its sub-routers.

Timings are written to the response header for now in the form:

1. X-Total-Response-Time - this is the overall time it took a request to processed by the server. The timer starts when the server gets the request and is calculated when the final response is sent

2. X-<endpointName>-Response-Time - the time it took a particular endpoint to process a request

3. X-<endpointName><subrouterName>-Response-Time - the time it took for a sub router to process a request. For example, X-GitapiCommit-Response-Time, which would be the overall time for the commit sub-router of the gitapi endpoint to return a response.

Noticably absent is timing collection for sub-routers of the /cfapi endpoints. This is intentional to avoid conflicts with current work happening in those routers.

We should also look at (in a separate bug) adding support for statsd so we can collect long-running stats and look for / investigate trends for performance improvements.
Comment 3 Eric Moffatt CLA 2017-09-26 10:09:02 EDT
Mike, it looks like these fields arent' showing up in the JMeter response field. Not sure why...
Comment 4 Michael Rennie CLA 2017-09-26 11:40:15 EDT
The PR has been merged for the remainder of 16.0 so we can collect some numbers for the remainder of the time leading up to the release.

I am going to leave this bug open because we have to back out the changes since we do not have an approved CQ to ship with the response-time dependency.

The CQ is here: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=14338
Comment 5 Michael Rennie CLA 2017-09-26 11:42:56 EDT
Moving to 17.0, since that is when this can actually be "fixed"
Comment 6 Michael Rennie CLA 2017-10-05 09:11:23 EDT
CQ is approved. 

Everything is merged.