Workers global variables concurrency

As the documentation indicates, global variables are within the scope of the instance of the script itself (on the VM it’s running on?). I want to know if, in a high concurrency environment, it’s safe to increment a global variable without losing data… is it an atomic operation, like an INCR in Redis?

Also, I’m trying to create some counters that I will periodically push to a central service. I’m hoping to do this by using global variables and after short periods of time upload the data from the workers (so that if the script goes down I don’t lose too much data). Is there a better way of doing this (I’m assuming sending out a beacon for every request using a fetch is not something that will be very efficient).

At the moment I am seeing 2-3 workers in the same datacenter serving the same client on different requests.

You can’t rely on global variables for an accurate increment counter.

If it is just an accurate increment counter, that doesn’t show anything back to the client you could use Redis, and benefit of event.waitUntil(...)

I thought I would do that, but does that mean that we’ll be paying for each out these outbound requests to redis as well? Also, that would cause a huge number of outbound requests as well, which might end up throttling/ratelimiting even my script itself. I’m currently doing about 15M requests/day passing through workers.

You don’t pay for outbound requests, only inbound requests that trigger a worker execution. If you use a event.waitUntil() like adaptive said, then it shouldn’t really impact your worker’s response time.

Personally got a worker that handles a couple million requests per month, and for each request I send off a log entry to a elasticsearch instance with event.waitUntil(), and personally I haven’t seen it impact or throttle the worker

hmm… I’m talking about 15M/day, and that will increase very quickly. I’ll give it a shot though.

Maybe I can just open a websocket connection and keep it open and send data over it, if global variables are retained across runs I guess even global objects like a websocket can be shared?

redis is the best option or adding nsq.

Workers don’t support websockets currently.

We currently do this for Logflare. Cloudflare doesn’t seem to care and as long as you use event.waitUntil() you get 30 seconds to complete the request.

There are some caveats to subrequests. Like if you get a lot of programmatic traffic you’ll trigger a 2k/minute subrequest rate limit. If you’re serving an API to API clients for example…

If you want to send that stuff to Logflare, you can just send us structured events. That way you have the context and can run SQL over it all via BigQuery. It also make viz via Data Studio very easy. Happy to help.

Thanks… we already collect a lot of data from a beacon that fires from our pages themselves (and then send it to BigQuery, then aggregated to DataStudio visualizations. However, all that process takes time (aggregation etc) and money. What I wanted to do was to be able to just increment in-memory (Redis) counters to have aggregated data for very cheap.

You mention the 2k/min subrequest limit… is there some more documentation around it, because one of my script is basically a “url expander/corrector” through which all my traffic passes, very often much more than 2k/min, so for 15M incoming calls there’s 15M subrequests as well (that actually fetch() the content). Are you saying this will be rate-limited? That would beat the purpose of having Workers, I think. I currently see a 100% success rate in Worker Analytics. I’m on the Enterprise plan.

Nice! I’d be interested to chat more about your setup maybe we can help each other out somehow. We’re doing about 4k events a second on average. Hit me up at [email protected] if you’re up for connecting.

I’m not sure this limit applies to enterprise plans. It’s also not relevant unless you’re getting a lot of programmatic traffic from one IP. If you’re not getting reports of serving a 429 status code then you’re probably fine. If this is already rolled out you’re probably fine. There is no documentation on this rate limit.