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

Using with AWS Lambda #345

Open
outerlook opened this issue Jan 10, 2022 · 4 comments
Open

Using with AWS Lambda #345

outerlook opened this issue Jan 10, 2022 · 4 comments
Labels
discussion 🗣️ Something needs discussion

Comments

@outerlook
Copy link

Hey, can someone confirm I can use this with AWS Lambda?

I've been trying to use GAds API with lambda but my functions keep timing out. I've tried with 1 min timeout/ 1024 mb memory (although it only reaches 360mb max).

Locally it works well with the same config and function. My lambda is not in a VPC. I've tried different operations (query/mutate) with no success, even the simplest.

Thanks in advance for any experience shared.

@outerlook
Copy link
Author

To better define my environment if someone is getting the same behavior, I use:

  • AWS-CDK (so it builds actually with esbuild to upload the zip)
  • Node v14

The hardest part is that it doesn't error anywhere. I don't truly know if the error is on which side. It just hangs even if I try to list customers for a refresh key (that works locally)

@rosslavery
Copy link

Not much more help but should be noted Opteo is aware of some of the challenges of running inside Lamba environments:

Opteo/google-ads-node#17

@outerlook
Copy link
Author

Thanks, @rosslavery !
A lot clearer to know there is WIP or even just not fully explored yet. Then I know I am not missing something obvious. :)

@Zikoel
Copy link

Zikoel commented Jan 13, 2022

I have another experience. This was with google cloud run that is slightly different but maybe AWS lambda works in a similar manner. What I have experimented* is that the resource attibution for a single run follow this steps:

  1. An externat trigger fire the execution (http requesto, scheduling etc etc)
  2. Resources was assigned to the runner (ram, cpu) etc etc
  3. Call to your code
  4. wait for response
  5. Resource deallocation
  6. Wait the runner gracefully shut down

Now if in my code I do this:

  1. handle the request
  2. do the hard work
  3. respond to the http request
  4. gracefull shutdown

all go as expected... BUT if I do this:

  1. handle the requeste
  2. respond to the http request
  3. do the hard work
  4. gracefull shutdown

here the job take a very long time and reach the timeout because after point 2 and before point 3 google remove all the allocated resources and leave only something very neglettable waiting your complete shutdown.

So the poin is: are you sure that you do the hard memory consuming work on the right place ? Maybe this is something that happen only in google cloud but keep me almos an entire day before debug the problem... so maybe a double check can be usefull.

* The experiment was done some months ago so maybe in the meantime things are changed and actually I don't find the docs where this behaviour was documented.

@kritzware kritzware added the discussion 🗣️ Something needs discussion label Feb 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion 🗣️ Something needs discussion
Projects
None yet
Development

No branches or pull requests

4 participants