{"id":46093,"date":"2022-04-07T00:00:00","date_gmt":"2022-04-07T00:00:00","guid":{"rendered":"urn:uuid:6c4cc37c-85c7-935c-4f15-d4daf02a184a"},"modified":"2022-04-07T00:00:00","modified_gmt":"2022-04-07T00:00:00","slug":"how-to-optimize-your-lambda-code","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/how-to-optimize-your-lambda-code\/","title":{"rendered":"How to Optimize Your Lambda Code"},"content":{"rendered":"

<\/p>\n

<\/div>\n

This code worked well in our tests and was approved in the code review process. It returns True when there are two files with the right prefixes, and it returns False when there isn\u2019t. Simple enough.<\/p>\n

That wasn\u2019t what happened in real life, however. It would still work in the scenario where the right files are there, but it would, only sometimes, return True when just one of the files were there. And this was frustrating because it was happening in production and only sometimes<\/i>. Nothing is more annoying than \u201csometimes.\u201d<\/p>\n

Let\u2019s figure this out<\/span><\/p>\n

Don\u2019t try this at home kids, but the first idea that came to mind to troubleshoot the problem was to edit the Function code and add a \u201cprint(files)\u201d between the two \u201cfor\u201d loops. This way I would be able to check the files array content before looping through all its contents. Then I checked the bucket and saw that there was just one file there, with the right prefix. Right away I executed the code and in that line the code printed exactly what I was hoping for, array had only the right item, and it returned False, as expected as well.<\/p>\n

I was confused. I ran the code again, just because I was out of ideas. To my surprise, the code returned True this time. I was twice as confused as before. That print output now showed the right file there\u2026 twice! There were 2 objects with the same key in the same bucket, which we know is impossible. Right away I went to check if versioning was enabled on said bucket, maybe that was the issue. But it wasn\u2019t. Versioning was off. I ran the code again, and once again, it returned False and printed the filename just once.
Feeling more lost than I already was in the beginning of all this, I stopped, took a deep breath, and tried all over again. First execution, False with printing the file name once. Second, returned True printing the file name twice. Third, returned False, printing the filename thrice. Clearly there was something wrong with this files<\/i> variable.<\/p>\n

What I got wrong<\/span><\/p>\n

Any beginner developer knows the concept of Scope, even if the name isn\u2019t known. For those who don\u2019t, Scope can be defined as a variable that is declared is only available inside the region it is created. If we go back to our code, we can see that the variable files<\/i> are declared in the global scope (in the function root, outside of any function\/method). I moved this declaration to inside the lambda_handler<\/i> function scope (right before the counter declaration) and it worked! An execution would ways return False and print the filename just once given my bucket content. So, what happened?<\/p>\n

We tend to oversimplify everything for our own sake. In Lambda\u2019s case, why would we overthink how the process behind running our code works if in the general case, \u201cit just works?\u201d This was one of the cases that understanding the (fascinating) process was helpful, and it can be to you too.<\/p>\n

How it actually works<\/span><\/p>\n

The Lambda execution environment lifecycle has three distinct phases: Init, Invoke and Shutdown, which are defined by AWS as:<\/p>\n