Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix average functions duration calculation in metrics output #3067

Merged
merged 22 commits into from
Feb 14, 2017
Merged

Fix average functions duration calculation in metrics output #3067

merged 22 commits into from
Feb 14, 2017

Conversation

vladholubiev
Copy link
Contributor

What did you implement:

Closes #3066 + refactoring of AWS Metrics plugin

How did you implement it:

Before:
Previously it was summing durations from each day and dividing it by number of Lambda functions, instead of number of data points from CloudWatch.

After:

const durationAverage = _.meanBy(getDatapointsByLabel('Duration'), 'Average') || 0;

Also refactored some code to increase readability (I hope) and "code churn" metric 😅 I was careful and all the tests are still passing, so should be ok.

How can we verify it:

This can be verified by:

  1. Unit test: should display correct average of service wide average function duration
  2. By manually checking service wide metrics for a large period of time for 1 function. Previously you would see abnormally high value.

Also I'm not sure whether the code coverage dropped or not. It dropped by statements, but increased by branches.

before:
Statements   : 95.63% ( 2624/2744 )
Branches     : 90.26% ( 1056/1170 )
Functions    : 97.55% ( 279/286 )
Lines        : 95.71% ( 2587/2703 )


after:
Statements   : 95.53% ( 2587/2708 )
Branches     : 90.72% ( 1046/1153 )
Functions    : 97.56% ( 280/287 )
Lines        : 95.62% ( 2552/2669 )

Todos:

  • Write tests
  • Write documentation
  • Fix linting errors
  • Make sure code coverage hasn't dropped
  • Provide verification config/commands/resources
  • Enable "Allow edits from maintainers" for this PR
  • Change ready for review message below

Is this ready for review?: YES
Is it a breaking change?: NO

@vladholubiev
Copy link
Contributor Author

vladholubiev commented Jan 6, 2017

Also docs looks strange (2001 and 2002). But they are ok in repo.

image

@pmuens
Copy link
Contributor

pmuens commented Jan 7, 2017

Thank you very much @vladgolubev you rock 🎸 !

Awesome PR description! 👍 We'll look into it ASAP!

@pmuens pmuens added this to the 1.7 milestone Jan 18, 2017
@pmuens pmuens self-requested a review January 18, 2017 12:39
Copy link
Contributor

@pmuens pmuens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really, really good refactoring!

Nicely done @vladgolubev love it (I always love it when more code is removed rather than added) 🥇 👍

I added 2 minor comments. Usually it's better to have function based PRs (so in this case one PR for the refactoring of the metrics plugin, one for awsProvider, one for configCredentials etc. which makes the PR easier to review and also easier to track down specific PRs when they introduce bugs) but these changes are not that major so it's fine to merge them here as well.

Again great job @vladgolubev GTM from my side once the comments are discussed / resolved 👍

@@ -182,6 +182,10 @@ class Service {
return Object.keys(this.functions);
}

getAllFunctionsNames() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be covered by a test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, thanks @pmuens, just pushed the changes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

(env.HOMEPATH ? ((env.HOMEDRIVE || 'C:/') + env.HOMEPATH) : null);

if (!home) {
if (!os.homedir()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is os.homedir() also safe for old Node versions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the list of Node versions we "officially" support:

- node_js: '4.4'
- node_js: '5.11'
- node_js: '6.2'
- node_js: '6.2'

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Hm, added in v2.3.0 - means safe.

My reasoning was, that I noticed that unit tests are using os.homedir() but the code not. After git blame found out it was because after refactoring project structure file was just copy pasted, and tests were written after by a different person. So just minor inconsistency.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. That totally makes sense.

I copied the code for the homedir detection from an old PR and pushed the test on top of that 😬. But yes, if the test use os.homedir and work for all node versions on our CI system, then the usage of os.homedir should work in the main code as well 😆 🤦‍♂️

@vladholubiev
Copy link
Contributor Author

vladholubiev commented Feb 7, 2017

@pmuens thanks for the review and feedback! Sorry for absence, I'm back here )

Usually it's better to have function based PRs

I strongly agree for that!! But with this PR the story was a bit different.

When you released metrics support in some of the recent releases, I, was impressed. So I went to the sources to read the implementation. After reading, I created a note to myself to refactor that file, as it's a great functionality, but no so readable as I could wish.

So I started refactoring it at that time, and after unit tests, I moved to testing it with my AWS account.

And at that time I realised that outputs differ from my local sls branch and what is published to npm. So I started digging into it to find where is my bug.

But in the end, it occurred on contrary - my refactoring fixed a bug I didn't have an idea about.

So, refactoring without any purpose resulted in a bug fix. Of course, afterwards I could fix couple of lines in the old code knowing the reason, and submit a new PR with just a refactoring, buuut, this didn't happen, it wasn't already so interesting for me, so all I can say to forgive me

Copy link
Contributor

@pmuens pmuens left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the update @vladgolubev 👍

Just gave it another spin and it works as expected. 💯

so all I can say to forgive me

No hard feelings! We love the stuff you do you so keep up the great work 🥇 👍

@@ -182,6 +182,10 @@ class Service {
return Object.keys(this.functions);
}

getAllFunctionsNames() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

(env.HOMEPATH ? ((env.HOMEDRIVE || 'C:/') + env.HOMEPATH) : null);

if (!home) {
if (!os.homedir()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep. That totally makes sense.

I copied the code for the homedir detection from an old PR and pushed the test on top of that 😬. But yes, if the test use os.homedir and work for all node versions on our CI system, then the usage of os.homedir should work in the main code as well 😆 🤦‍♂️

Copy link
Member

@eahefnawy eahefnawy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vladgolubev I love how extensive your lodash usage is! ❤️ It helps refactor tons of LOCs

Approved!

return _.get(this, 'options.region')
|| _.get(this, 'serverless.config.region')
|| _.get(this, 'serverless.service.provider.region')
|| defaultRegion;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

const invocationsCount = _.sumBy(getDatapointsByLabel('Invocations'), 'Sum');
const throttlesCount = _.sumBy(getDatapointsByLabel('Throttles'), 'Sum');
const errorsCount = _.sumBy(getDatapointsByLabel('Errors'), 'Sum');
const durationAverage = _.meanBy(getDatapointsByLabel('Duration'), 'Average') || 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❤️

@eahefnawy eahefnawy merged commit cc94945 into serverless:master Feb 14, 2017
@vladholubiev vladholubiev deleted the fix-average-functions-duration branch February 14, 2017 13:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants