Hi. Is there any additional network limits applied to a cron worker, compared to an ordinary worker invoked by an outside request? I get a strange 404 from my cron worker. The cron worker does a request to another worker through a service binding, which in turn tries to do a request to an external api. The fetch request to the external api fails with 404 when invoked from the cron worker. But if i trigger this from the outside (Postman for example) it will succeed.
Kian: Ok interesting. This problem reminds me of when I tried to make fetch request directly to other workers within the same zone. The external API in this case is actually done through a proxy worker within the same zone. But I understand you are saying that there should be no difference depending on how it's triggered
Could the service you are fetchfetching be region-locked? The Cron Worker might run in a different datacenter than where your regular HTTP-triggered Workers requests run.
How do workers perform when it comes to CPU heavy tasks? Like I want to encode a GIF which takes around 10 sec on my local PC, but when I run it on a Server with quite a good CPU it get it down to ~2 seconds. If I now ran it inside a worker, would I rather see an increase in time for encoding, or a drop-off in time required?
My main concern is just that I might hit the 30 sec timeout limit (for HTTP requests) if the encoding is slower on workers than on my PC, for example. And since I am unable to find any concrete numbers on the CPU performance on the website, my best bet was that maybe here someone knows if how they perform on that type of task or even has some experiences with that kind of workers.
As an example of what Workers+WASM can do, you can check out https://og-playground.vercel.app/. In general, CF won't provide direct CF metrics, but I would say, for light/moderate loads, go with Workers+WASM, for heavy+ loads, go with something like https://fly.io
In general a good Idea however since I want to encode "on demand" I probably can't use cron jobs since I want to do it every time a user calls an endpoint. Thanks though!