Workers & Cached Subrequests + Pricing

#1

Hi all,

We currently use Workers to take some load off our Azure instance, by handing high volume polling from Android devices (reporting their health). We receive the request, pass the JSON data to an Azure queue and return a response. Azure handles the queue in the form of a Function (which works incredibly well).

Before returning the response, we have to look up a json list of identifiers, the list typically contains anywhere from 5-100 identifiers). If the request identifier is in the list we modify the response to tell them to stop polling (never poll again). The list is stored as a .js file on Azure Blob storage and is successfully cached by cloudflare (confirmed by logging the output of cached=HIT).

So, all of that is working like a dream, so much so we have scaled back Azure instances.

As you can see from the below there are a huge amount of cached requests (relating to the json list lookup). I gather we are effectively billed for total requests, including cached requests. So whilst we have taken the load off Azure (including the json list on blob storage), I’m wondering if there is any way we can optimise this further and potentially reduce the cost (all those cached requests). I’ve looked at KV workers but we are effectively billed the same $0.50 per million reads vs $0.50 per million requests.

If nothing else, I wanted to post this as a great use case for workers!

#2

You could fetch your json, store it as a global variable on your worker, provided that is not too big. If global variable empty, fetch or get KV. You might need to create a TTL as global variable.

#3

Sounds like a good idea. Json data is probably only ever going to be max 5kb.

#4

If all the script with that json is less than 1 MB and not that often updated, then import, webpack and terraform/serverless to push it to Cloudflare.

#5

Thanks for your thoughts!

#6

Just thinking about TTL, for some reason the JS Date() object returns 1970 in the editor and if I log it out in production. Thoughts?

#7

Date.now() should return epoch now

#8

Ah I was just messing around outside of the main function, returning 1970 but inside the main function its fine.