anderly
Exceeded CPU errors
First off, this is a great library. I've implemented it and its been easy to use. Thanks for sharing.
Unfortunately, I'm pretty confident at this point that this takes too much time to execute and will eventually lead to a Exceeded CPU error. The problem is that Cloudflare doesn't start throwing that error until you hit serious traffic in a short period of time (somewhere in the range of 1-5k hits within a 5 minute period is what I've gathered).
Once i removed the router I've eliminated that error. It was a pain to troubleshoot because Cloudflare doesn't provide any insight into what is going on on their end.
It may also depend on how many routes you have configured. I have 8 routes set up in my scenario.
Just want to make any others aware and save them countless hours of troubleshooting I spent on this :)
@fellars,
Thanks for your feedback and opening this issue. @kentonv mentioned in this thread that the “exceeded CPU” error actually means “exceeded resource limits." So, it could be that we're going over the memory limit somehow under load.
@kentonv, any recommendations on how to troubleshoot and isolate a root cause of the “exceeded CPU” error within a CF worker?
@fellars, the router is currently using regex which could be hitting memory issues under load. Another possibility is maybe responses are not getting streamed and are counting against memory limit.
I'm going to review the code again to see if any issues like this stand out.
Thanks again for the heads up!
@anderly - its possible, although I've gone back and forth with @kentonv on the threads to get more insight (I'm the dev40 user on that thread) - check his answer here
I had the same thought regarding memory usage but that comment implies its the CPU issue.
Ok, thanks for clarifying. The router is the only substantial amount of code in this library, so I think that's got to be where the issue is. I'll review and let you know if I find any obvious issues.
You almost certainly are not hitting the memory limit. We've changed things so that we soft-evict workers when they hit the memory limit -- in-flight requests finish without error -- unless the worker goes 2x over the limit. Also, after hitting the memory limit, the next request would be handled by an all-new isolate.
Looking briefly at the library, it looks like it is re-parsing every route pattern and dynamically constructing regexes on every request. The library would likely be much more CPU-efficient if it converted the route patterns to regexes once upfront rather than every time it's trying to match a new incoming request.
@fellars Sorry that profiling workers is so hard right now. Part of the difficulty is that if we let people time code execution, they can use it to launch Spectre attacks. :/ We are working towards creating better tools (that provide timing but don't allow such attacks) but it's a big project.
@fellars Also you might try using https://github.com/dollarshaveclub/cloudworker to run your code locally, in which case you can freely time execution. (Disclaimer: I haven't tried this tool myself, but I've heard it works well.)
yeah, i'm guessing its the regex matching every time. It also loops through all routes instead of exiting after first found match.
i removed your library and am just using a simple indexOf on the url paths which is enough for my use cases and im no longer hitting the limits (fingers crossed!)
@kentonv - no worries - i understand its still bleeding edge. thanks for the link - hadn't seen that before.