Hey anyone know the reason for not being able to connect to a websocket through a global scope?
Hey anyone know the reason for not being able to connect to a websocket through a global scope?
IJust seems a little resource intensive to connect to websocket each request
HWorkers are started up, then snapshotted. If you were able to initialize a WebSocket in the global scope, it would be invalid, since the connection itself would no longer exist
Ioh i see thank you
Ii just realize i can implement a caching mechanism too
Iso i can retrieve data faster
W
what's your account ID?Woh local only
Jyeah
WYeah report that on github
Jwhich repo would you suggest?
Whttps://github.com/cloudflare/workers-sdk and they can move if it needs to go elsewhere
KHow is the limiter controlled, or is it just total requests from all sources/origins against the entire worker/namespace?
Jreqs by namespace as far as I know, yes
JGitHub
Which Cloudflare product(s) does this pertain to? Workers Runtime What version(s) of the tool(s) are you using? 3.48.0 [wrangler] What version of Node are you using? 21.7.1 What operating system an...
PHey
PWhat do you guys suggest I should do?
PToday I noticed that I got a timeout on my webhook in my repo
PMost probably because the issuing server that does the request to my worker was slow
Pand I consume the API of that same server
PI was thinking moving to queues but it's not free 
Tit works but it keeps saying Worker exceeded CPU time limit.
JWhen doing what?
Twhen I use the Unpdf package to extract the text from the pdf. maybe the CPU time for worker take long time to parse the whole pdf and extract the text
JRight.. if you're doing a lot of work you might exceed the limits
JTry splitting it up into tasks
LWill Worker to Worker communication (especially RPC Calls), be cheaper then normal Requests in the Future? I mean it's much less then a normal HTTP Request and should therefore be cheaper or not?
BIt will, they've said they're making it free I think
Bfor the request
HUnder the hood, Worker-to-Worker coms are via Capn'Proto messages, so it can't get much cheaper
Bcompute still costs, of course
B(I could be wrong, please correct me)
BI think I saw this in a tweet
LThanks for the quick answers. @HardlyWorkin' but it's still less then a Request from Outside of the Cloudflare Network.
LThe Request should be cheaper and compute time should still be charged ofc
HOh, like that. Thought you were talking about something else sorry
LI think it'll be cheaper otherwise no one would use the maybe announced Plugin Store ^^ bcs that would be hella expensive if i have like 10+ Plugins enabled
NWhich one is it?
Nnvm im blind
N10k a day = 300k/mo
B@sperand_io @elithrar @Cloudflare Two things here:
- We are working on (couldn't quite make it for this week) a change where when you call another Worker via a service binding, this won't be billed as a request. (so that pricing doesn't disincentivize breaking apart an app into many Workers) Coming soon.
4/5/24, 7:31 PM
BWe are working on (couldn't quite make it for this week) a change where when you call another Worker via a service binding, this won't be billed as a request
NOOOH NICE
LThats nice, ty
Bthe reason they can do this as far as I can tell is because they're colocating it
LThat will open up alot of possiblities actually
BRPC to another Worker (over a Service Binding) usually does not even cross a network. In fact, the other Worker usually runs in the very same thread as the caller, reducing latency to zero. Performance-wise, it’s almost as fast as an actual function call.
BYeah, so I think addresses the point about "they can't reduce it all the way" - with this architecture, it becomes super cheap
NIs workers AI free for beta models?
NOr am I misunderstanding.
IThat's correct, yes.
