9

If I want to use GCP Cloud Function to automate (also parallelise) image recognition using VISION API (Python3), but CF has a hard limit of 9 minutes duration. What if a image is very big, and takes a long time be recognised (longer than 9 minutes)? Any suggestions?

FishingSlark
  • 115
  • 1
  • 5

2 Answers2

4

In the Cloud Function code, you can offload the work to App Engine or Compute Engine.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • 1
    It's not very difficult. You simply turn around and make another API call from your function that's more suitable for long-running operations. You can easily create a flexible App Engine services with an HTTP API that lets you kick off some work. It'll spin up server instances as needed that perform the work. This is more scalable, flexible, and cost effective than writing a bunch of code to make Cloud Functions do something it wasn't intended to do. – Doug Stevenson Oct 19 '18 at 03:26
  • interesting, but how can you ensure the parallelization and efficiency of the job? – FishingSlark Oct 22 '18 at 05:09
  • That's up to the service where you offload the work, not Cloud Functions. – Doug Stevenson Oct 22 '18 at 06:10
0

The Cloud Vision APIs offer an asynchronous version of the API calls, that will return an operation ID for the job.

I would create two Cloud Functions to handle this situation. The primary function would start the async operation and the response code should match whether you were able to start the job, with the body containing any details you want along with the OperationID to follow up on.

A second function would accept an operation id and check the current status and if the operation has finished return the result. Whether the function polls for a period of time internally or only does a quick check and immediate response is up to you and how you want the process to work. I would likely have the frontend display a 'processing' icon and check every 10s or so with an immediate response.

FridayPush
  • 871
  • 5
  • 7
  • You can't have a cloud function that polls. They are invoked in an event-driven manner. I suspect that the cloud vision API will not be able to generate an event that could trigger the second function. – Doug Stevenson Oct 18 '18 at 23:03
  • You can poll manually inside of your function, using any sort of async function that waits for the result or times out after 60s. For example making the request in a loop at 5s intervals, if after 60s it returns. Just to clarify, I was imagining the front end making a request to the poll function once every 10s or so. Alternatively the front end makes a request and holds it open until the request ends if the internals of the function is doing the polls against the operation. – FridayPush Oct 19 '18 at 00:04
  • If you poll in your function, you just run into the same timeout problem described by the OP (9 minute limit). – Doug Stevenson Oct 19 '18 at 00:59
  • I didn't explain my thoughts well. I suggested the quick resolving function that you poll at intervals, but another thought was that if your images are generally processed earlier say <60s you could establish a connection and wait for a response if the response is that the operation is ongoing you can retry. As it's just checking for an operation it's idempotent and doesn't really matter how many times you call the function. It'd be more expensive to allow the function to run for 60s x 9, then polling externally anyway. So I probably shouldn't have suggested it as a secondary alternative. – FridayPush Oct 19 '18 at 02:42
  • Thanks. I will give it a try, and see how it goes. – FishingSlark Oct 19 '18 at 02:45
  • Given that you're billed in Cloud Functions for the duration of the function execution, it doesn't seem cost effective to poll and/or keep a function alive that's not really doing anything. This kind of an anti-pattern for serverless backends. – Doug Stevenson Oct 19 '18 at 03:19
  • You're right, so I shouldn't have suggested the second alternative. – FridayPush Oct 19 '18 at 03:21
  • And the problem with the first option is that you can't know when the work finishes. – Doug Stevenson Oct 19 '18 at 03:25
  • I'm disagreeing with your opinion that polling externally is a problem or an anti-pattern. I'm agreeing that polling internally to the function and exiting after 60s is a bad idea. The charge of 36 function invocations is only $0.0000216 to poll every 10 seconds for 9 minutes. Offloading the work to a GAE standard with min instance of 0 would still generate a 15m minimum charge for starting a clone. – FridayPush Oct 19 '18 at 03:37
  • When you have a reasonable amount of load, the cost is amortized across all the invocations it'll be handling. If you just have a couple items of work to occasionally, then I guess you can do whatever you want. But Cloud services are meant to scale massively, and polling isn't a massively scalable operation. – Doug Stevenson Oct 19 '18 at 16:07