Answers: <p>Check out the <a href="https://read.iopipe.com/using-iopipe-profiling-to-gain-crucial-observability-into-your-aws-lambda-functions-506f5dda6bdf" rel="noreferrer">IOpipe profiler</a> to get full v8 profiler dumps from Lambda invocations.  You can load those into Chrome Devtools to see exactly where CPU time is spent, and how memory is being used for your functions.</p>
  
  <p><a href="https://i.sstatic.net/0mshm.png" rel="noreferrer"><img src="https://i.sstatic.net/0mshm.png" alt="enter image description here"></a></p>
  
  <p>Disclaimer: I work for IOpipe</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-19T21:23:05.480Z
Answers: 2018-01-19T21:23:05.480Z
Answers: adjohn
Answers: <p>I might not be able to answer it completely, but here are my views from my limited experience with lambda:</p>
  
  <ol>
  <li><strong>Speed-Performance:</strong> The duration of a single run of a lambda function will be present in the dashboard of the Lambda's <code>monitoring</code> tab, which looks something like this:</li>
  </ol>
  
  <blockquote>
    <p><a href="https://i.sstatic.net/wp87u.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/wp87u.png" alt="enter image description here"></a></p>
  </blockquote>
  
  <p>So do throttles/errors/number of invocations.</p>
  
  <ol start="2">
  <li><strong>One can also set up CloudWatch filters for the memory usage</strong> of a lambda function, whose data can be used to further optimize your handler. <a href="https://forums.aws.amazon.com/thread.jspa?threadID=226674" rel="nofollow noreferrer">This</a> is a decent post on how to set one up.</li>
  <li>Also, <strong>set up proper logging</strong>, so that you can later go through the logs in CloudWatch.  This isn't an optimization hack per se, but more of a best practise</li>
  <li><strong>Testing</strong>: Test your lambda functions thoroughly, so that you don't miss out on edge cases. This is important, as lambda retries failed functions before giving up. So, you can save up on time forehand if you tested the function properly. <a href="http://docs.aws.amazon.com/lambda/latest/dg/with-on-demand-https-example-create-test-manually.html" rel="nofollow noreferrer">Guide to testing Lambda functions</a></li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-03T02:44:36.300Z
Answers: 2017-03-03T04:35:09.853Z
Answers: 2017-03-03T04:35:09.853Z
Answers: Dawny33
Answers: <p>Use <a href="https://github.com/stackimpact/stackimpact-nodejs" rel="nofollow noreferrer">StackImpact agent</a> to get CPU and memory profiles. More details in the blog post: <a href="https://stackimpact.com/blog/aws-lambda-cpu-and-memory-profiling-node-js/" rel="nofollow noreferrer">AWS Lambda CPU and Memory Profiling (Node.js)</a>. Because Lambda Node.js process is freezing between requests, most of the other tools will probably not work out of the box.</p>
  
  <p><a href="https://i.sstatic.net/AwxNM.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/AwxNM.png" alt="enter image description here"></a></p>
  
  <p>Disclaimer: I work for StackImpact</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-10-20T09:17:03.943Z
Answers: While it sounds related and potentially a valid solution, extending a little on how it may help addressing the question would avoid the feeling of a link only answer where if the link rot there's not much to get a first idea on how it may help.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-10-19T15:25:32.507Z
Answers: 2017-10-19T15:25:32.507Z
Answers: logix
Answers: <p><a href="https://devops.stackexchange.com/a/257">Dawny33 response</a> is good, but I would start earlier in the development process.</p>
  
  <p>Keeping an eye on your cloud environment to make sure that your functions behaves as you expect (including your "production" functions, which might operate on a different data set) is crucial, because it might reveal things that are impossible to reproduce locally or with a test data-set.</p>
  
  <p>Nonetheless, I would say that this performance testing that you do in an optimization purpose should start straight from the developer's machine. Or, at least, from some local environment before pushing to the cloud.</p>
  
  <p>The reason I say so is that while AWS Lambdas are amazing on many points, the fact that you don't have a full control on the server will limit your instrumentation abilities. I'm not saying instrumentation is impossible when in serverless, but try figuring out how many CPU interrupts you have (and how many are caused by <em>your</em> code) just for fun ;)</p>
  
  <p>So what I advise, and this is actually not limited to serverless, is to start the profiling early. NodeJS profiling can be made with many different tools, NewRelic, dynatrace and AppDynamic are some of the big players. There is also smaller player, some of them are just a NPM package to install (like Nodefly). It is also possible to do some NodeJS without any additional tool, as there is a profiler built into the V8 engine. <a href="https://nodejs.org/en/docs/guides/simple-profiling/" rel="nofollow noreferrer">This documentation</a> from NodeJS will get you started.</p>
  
  <p>Whatever tool you choose, you want to install it locally and collect profiling data. That might involve running an agent or including a package in your package.json. Your tool's instructions will tell you how to install it. A good profiler will let you know how much memory and CPU you use. Better tools will give you insight on how many remote calls were made, how long they took.</p>
  
  <p>Use the profiling data that the tool gives you to identify bottlenecks and address them. There's no limit on how much profiling you can make. Some people (crazy?) will look at the system calls of their most critical function. You might have to do that kind of thing if you want to shave nanoseconds of your function (but then, maybe AWS Lambda isn't the best choice to start with).</p>
  
  <p>It's also worth noting at this point that I haven't mentioned anything specific to AWS Lambda. That's because your optimizations will most likely not be AWS Lambda specific (after all, in serverless you shouldn't be worried about the server/environment).</p>
  
  <p>Make sure that not only your code works, but that it works the way you expect it to. Don't over optimize, but keep a critical eye on CPU and memory usage. Should a 2MB array really grow to 10MB when you sort it? Probably not.</p>
  
  <p>Then you will be able to use tools mentioned by Dawny33, or some other tools, to confirm that your functions perform similarly when deployed to Lambda. You will however already have a very high level of confidence in your function and will only need to validate that they behave properly, not fully profile them.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-03T04:00:42.663Z
Answers: Yes, it is important, but *how* can it be done? Are there some tools, practices, what exactly can a developer do? I don't see any of this mentioned in this answer :/
Answers: Evgeny Zislis
Answers: CC BY-SA 3.0
Answers: 2017-03-03T04:09:18.420Z
Answers: I said so, through profiling and instrumentation. NewRelic APM is an example, but that's just one of the profilers available. Install the profiler, run your function, optimize. Whether it will run on AWS Lambda doesn't matter, unless you have a problem specific to AWS. I will update my answer based on your comment.
Answers: Alexandre
Answers: CC BY-SA 3.0
Answers: 2017-03-03T04:11:04.390Z
Answers: Some examples and links to articles, blogs, known profilers that can do the job. That is the kind of thing that imho makes the answer valuable, not just sending people to ask a question somewhere "how do I count my cpu interrupts, I have no clue".
Answers: Evgeny Zislis
Answers: CC BY-SA 3.0
Answers: 2017-03-03T04:23:08.163Z
Answers: Good point. I have improved my answer again.
Answers: Alexandre
Answers: CC BY-SA 3.0
Answers: 2017-03-03T03:57:08.497Z
Answers: 2017-03-06T17:18:39.620Z
Answers: 2017-04-13T13:01:29.297Z
Answers: Alexandre
Body: <p>AWS Lambda cost is dependent on the time a function runs, and to some extent on memory footprint. Having functions that finish faster, and take up less memory can save quite a lot of money. Especially when such a function is executed often.</p>
  
  <p><strong>How can a Node.js Lambda function be tuned for speed and small memory footprint to save on cost?</strong></p>
  
  <p>Are there other aspects for Lambda that are advantageous to improve?</p>
  
Tags: <aws-lambda><performance>
Title: How to performance test AWS Lambda functions?
UserDisplayName: Evgeny Zislis
ThreadText: # How to performance test AWS Lambda functions?
  
  (Asked by: username_0 on 2017-03-03)
  
  AWS Lambda cost is dependent on the time a function runs, and to some extent on memory footprint. Having functions that finish faster, and take up less memory can save quite a lot of money. Especially when such a function is executed often.
  
  **How can a Node.js Lambda function be tuned for speed and small memory footprint to save on cost?**
  
  Are there other aspects for Lambda that are advantageous to improve?
  
  **Tags:** aws-lambda, performance
  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_5 on 2017-03-03. Score: 7 | Accepted answer
  
  [username_2 response](https://devops.stackexchange.com/a/257) is good, but I would start earlier in the development process.
  
  Keeping an eye on your cloud environment to make sure that your functions behaves as you expect (including your "production" functions, which might operate on a different data set) is crucial, because it might reveal things that are impossible to reproduce locally or with a test data-set.
  
  Nonetheless, I would say that this performance testing that you do in an optimization purpose should start straight from the developer's machine. Or, at least, from some local environment before pushing to the cloud.
  
  The reason I say so is that while AWS Lambdas are amazing on many points, the fact that you don't have a full control on the server will limit your instrumentation abilities. I'm not saying instrumentation is impossible when in serverless, but try figuring out how many CPU interrupts you have (and how many are caused by *your* code) just for fun ;)
  
  So what I advise, and this is actually not limited to serverless, is to start the profiling early. NodeJS profiling can be made with many different tools, NewRelic, dynatrace and AppDynamic are some of the big players. There is also smaller player, some of them are just a NPM package to install (like Nodefly). It is also possible to do some NodeJS without any additional tool, as there is a profiler built into the V8 engine. [This documentation](https://nodejs.org/en/docs/guides/simple-profiling/) from NodeJS will get you started.
  
  Whatever tool you choose, you want to install it locally and collect profiling data. That might involve running an agent or including a package in your package.json. Your tool's instructions will tell you how to install it. A good profiler will let you know how much memory and CPU you use. Better tools will give you insight on how many remote calls were made, how long they took.
  
  Use the profiling data that the tool gives you to identify bottlenecks and address them. There's no limit on how much profiling you can make. Some people (crazy?) will look at the system calls of their most critical function. You might have to do that kind of thing if you want to shave nanoseconds of your function (but then, maybe AWS Lambda isn't the best choice to start with).
  
  It's also worth noting at this point that I haven't mentioned anything specific to AWS Lambda. That's because your optimizations will most likely not be AWS Lambda specific (after all, in serverless you shouldn't be worried about the server/environment).
  
  Make sure that not only your code works, but that it works the way you expect it to. Don't over optimize, but keep a critical eye on CPU and memory usage. Should a 2MB array really grow to 10MB when you sort it? Probably not.
  
  Then you will be able to use tools mentioned by username_2, or some other tools, to confirm that your functions perform similarly when deployed to Lambda. You will however already have a very high level of confidence in your function and will only need to validate that they behave properly, not fully profile them.
  
  > **Comments:**
  > **username_0**: Yes, it is important, but *how* can it be done? Are there some tools, practices, what exactly can a developer do? I don't see any of this mentioned in this answer :/  
  > **username_5**: I said so, through profiling and instrumentation. NewRelic APM is an example, but that's just one of the profilers available. Install the profiler, run your function, optimize. Whether it will run on AWS Lambda doesn't matter, unless you have a problem specific to AWS. I will update my answer based on your comment.  
  > **username_0**: Some examples and links to articles, blogs, known profilers that can do the job. That is the kind of thing that imho makes the answer valuable, not just sending people to ask a question somewhere "how do I count my cpu interrupts, I have no clue".  
  > **username_5**: Good point. I have improved my answer again.  
  
  ---
  
  ### Answer by username_1 on 2018-01-19. Score: 5
  
  Check out the [IOpipe profiler](https://read.iopipe.com/using-iopipe-profiling-to-gain-crucial-observability-into-your-aws-lambda-functions-506f5dda6bdf) to get full v8 profiler dumps from Lambda invocations. You can load those into Chrome Devtools to see exactly where CPU time is spent, and how memory is being used for your functions.
  
  [![enter image description here](https://i.sstatic.net/0mshm.png)](https://i.sstatic.net/0mshm.png)
  
  Disclaimer: I work for IOpipe
  
  
  ---
  
  ### Answer by username_2 on 2017-03-03. Score: 5
  
  I might not be able to answer it completely, but here are my views from my limited experience with lambda:
  
  1. **Speed-Performance:** The duration of a single run of a lambda function will be present in the dashboard of the Lambda's `monitoring` tab, which looks something like this:
  
  > [![enter image description here](https://i.sstatic.net/wp87u.png)](https://i.sstatic.net/wp87u.png)
  
  So do throttles/errors/number of invocations.
  
  2. **One can also set up CloudWatch filters for the memory usage** of a lambda function, whose data can be used to further optimize your handler. [This](https://forums.aws.amazon.com/thread.jspa?threadID=226674) is a decent post on how to set one up.
  3. Also, **set up proper logging**, so that you can later go through the logs in CloudWatch. This isn't an optimization hack per se, but more of a best practise
  4. **Testing**: Test your lambda functions thoroughly, so that you don't miss out on edge cases. This is important, as lambda retries failed functions before giving up. So, you can save up on time forehand if you tested the function properly. [Guide to testing Lambda functions](http://docs.aws.amazon.com/lambda/latest/dg/with-on-demand-https-example-create-test-manually.html)
  
  
  ---
  
  ### Answer by username_3 on 2017-10-19. Score: 0
  
  Use [StackImpact agent](https://github.com/stackimpact/stackimpact-nodejs) to get CPU and memory profiles. More details in the blog post: [AWS Lambda CPU and Memory Profiling (Node.js)](https://stackimpact.com/blog/aws-lambda-cpu-and-memory-profiling-node-js/). Because Lambda Node.js process is freezing between requests, most of the other tools will probably not work out of the box.
  
  [![enter image description here](https://i.sstatic.net/AwxNM.png)](https://i.sstatic.net/AwxNM.png)
  
  Disclaimer: I work for StackImpact
  
  > **Comments:**
  > **username_4**: While it sounds related and potentially a valid solution, extending a little on how it may help addressing the question would avoid the feeling of a link only answer where if the link rot there's not much to get a first idea on how it may help.  
  
  ---
  
  