Serverless Cloud Tiny App Sharing Data

[MrGadget]

I'm looking at Google Cloud Functions and can't find a clear answer on whether data can be shared between requests.

I have this tiny NodeJS API.  Some requests will post a small chunk of data, other requests will retrieve a subset of the data posted.  All data is transient (expires in 90 seconds).  If there is no posting or retrieval activity, the app can shut down and forget everything.  No database...all data is held in memory (key value pairs).  No logging needed.  Nothing visual: the posters and requesters are using a fat client to push and pull the data.

I assume there can only ever be a single "instance" so that posted data doesn't end up in one instance and requesters are pulling from a different one and therefore wouldn't get some or all of the data.

Is this feasible for a serverless cloud API?

[Phillip Pearson]

Yes and no... if your traffic is low enough that only a single instance is started, that instance can cache data in memory, however when traffic increases and a second instance is started, this approach breaks down as the two instances are in separate containers and possibly separate machines.  The instance will be shut down after a while if there are no requests, but this probably isn't a problem here as I believe the timeout is more than 90 seconds.

You can force your function to only run with a single instance using the --max-instances flag at deployment time, but this will limit scaling; you'll see "429 Too Many Requests" errors if the single instance can't handle it all.  Details here: https://cloud.google.com/functions/docs/max-instances

Cheers,

Phil

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/4b525a7e-ca00-46c4-bada-3af48f21ff4f%40googlegroups.com.

[MrGadget]

Thanks for that.  Can you give me a sense of what "if your traffic is low enough" means in actual numbers?  10 concurrent requests? 100? 1000?

For our purposes, locking to a single instance, or perhaps regional instances that coordinate to users (e.g. America, Europe, Asia, etc.) is fine, even if it means responses are not instant.  The users aren't actually aware when the background task posts and retrieves data, so it's not like they'd be pounding a refresh button or some such.

[MrGadget]

Just to confirm, all these https posts and gets count toward the 2M / month in the free tier I linked originally?  We should be well under that.

[Phillip Pearson]

In GCF, each instance can only handle one request at a time, so it means one concurrent request.  To see what this means in the context of your app, you would have to try deploying it with --max-instances 1 and load testing, as it very much depends on how long each request takes to service.

If you're planning on handling hundreds or thousands of concurrent requests, you might want to try out App Engine or Cloud Run, both of which can handle multiple concurrent requests inside an instance.  That said, you're always going to run into the limits of a single instance if you don't use a database.  I would recommend using something like Redis (with persistence turned off), which you can provision via Cloud Memorystore or on a Compute Engine instance, which will let you share data between as many GCF / GAE / GCR instances as you need.

Cheers,

Phil

On Thu, Apr 9, 2020 at 6:34 AM MrGadget <ch...@langsenkamp.com> wrote:

Just to confirm, all these https posts and gets count toward the 2M / month in the free tier I linked originally?  We should be well under that.

--

You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-appengine/998d9c93-2bac-44c1-8814-93a19317f6c5%40googlegroups.com.

[MrGadget]

Sorry, but you're way over engineering for this tiny app.  No need for a database, or any back end we'd want to spend money or man hours on.  There are posters and retrievers.  Retrievers outnumber posters like 10 to one, but there will not even be dozens of concurrent requests, let alone hundreds or thousands.  Posting adds or updates tiny data to a name-value pair collection, retrievers get some subset of entries from that name value pair collection matching certain criteria. Entries are culled when they're 90 seconds old, so that collection never gets huge...few hundred entries at most. Posts and requests will take a few milliseconds to complete.  App does nothing with the data other than remember it for retrieval in that collection.

Being forced to single-threaded (1 concurrent request) was unexpected, but at least it saved me from coding in concurrency protection myself.

So now I have to ask, to what extent will my app be protected from junk requests that aren't actually from my users, e.g. bots, spiders, kids being stupid, etc.?  I just don't want to get a $1000 invoice from garbage traffic.  Can I put something in the HTTP headers such that any calls to the app missing that header are just discarded?

On Thursday, April 9, 2020 at 2:35:05 PM UTC-4, Phillip Pearson wrote:

In GCF, each instance can only handle one request at a time, so it means one concurrent request.  To see what this means in the context of your app, you would have to try deploying it with --max-instances 1 and load testing, as it very much depends on how long each request takes to service.

If you're planning on handling hundreds or thousands of concurrent requests, you might want to try out App Engine or Cloud Run, both of which can handle multiple concurrent requests inside an instance.  That said, you're always going to run into the limits of a single instance if you don't use a database.  I would recommend using something like Redis (with persistence turned off), which you can provision via Cloud Memorystore or on a Compute Engine instance, which will let you share data between as many GCF / GAE / GCR instances as you need.

Cheers,

Phil

On Thu, Apr 9, 2020 at 6:34 AM MrGadget <ch...@langsenkamp.com> wrote:

Just to confirm, all these https posts and gets count toward the 2M / month in the free tier I linked originally?  We should be well under that.

--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-a...@googlegroups.com.