-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Setting Global Timeouts beyond 60000 causes 500 error #989
Comments
I believe the reason we diagnosed before with changes on this service was that changing these options can result in the Fastly compute systems overloading your backend itself causing failures. Previously I believe @ulyssa discussed the fix to this being better controlling / restricting the concurrent connections made to your backend across the network to avoid overloading it. |
Yes, it is possible when increasing the connection or other backend timeout that all of the spots available for a given service get used up by instances of the service waiting on something to hit the backend. If they hit the max guest runtime (~120s) then they'll get killed and a 5xx error will be generated for them. When dealing with origin requests that might take a while to send a body, as long as it returns the response headers then you can send the response body handle and exit the guest. (I'm not entirely sure what this looks like in the JS SDK, but @guybedford may be able to point you at an example.) This then frees up the guest slot and its memory and allows handling a new incoming request while the response gets streamed in the background. |
We didn't see any increase of connections at the origin. In fact, we saw the opposite, nothing was getting through at all. |
Do you have a test service that you use here? Can you replicate the issue on the test service with a single request? Are you able to check the error logs for that 500 request to determine the 500 error data? |
This was the original error from the Compute. I'll setup a test next weekend.
Not very informative unfortunately as to the true cause. |
This is exactly the error for the timeout triggering. Yes a test setup would help to check it is the expected timeout behaviour. |
When we set:
to 180000 from 60000 the Compute experienced complete failure. According to the Fastly documentation, this value can go up to 4294967296 as per the documentation here: https://js-compute-reference-docs.edgecompute.app/docs/fastly:experimental/allowDynamicBackends#parameters
The text was updated successfully, but these errors were encountered: