Hi Rowan and Benjamin, we talked about this before and I think it's a good addition. Two > suggestions to improve the RFC: >
Thanks for the ideas, I'll incorporate more details about the interaction of these settings. And I've just collected a few examples when my proposal would be useful: https://gist.github.com/kocsismate/dbcc4ba81b27cfb2e25b949723bb7c79 . Their intention is to illustrate that no matter how tight the individual timeout settings are, if the number of external calls is high enough during the same request, nothing (*) can prevent the response time to skyrocket until all the workers become busy, causing outage because the web server can't serve any new connections. *except for some more complex, or non-clean mechanisms, which are outlined in the RFC, I'm struggling to picture when I'd want a hard wall-time limit, rather than: > - checking the script's duration at key points where I know it can > gracefully exit, ensure a consistent state, and return an appropriate > message to the caller > - enforcing a network timeout on the calling end so that I don't need to > rely on all services cooperatively exiting in good time In my opinion, the main problem with the first suggestion is that in most cases, non-trivial production code can barely do anything like "checking the script's duration at key points". If there are enough levels of abstraction, the outermost layers (e.g. controllers) can't do any checks, they simply have not enough control. On the other hand, having assumptions about the request duration in any inner layers (e.g. model if we take MVC as an example) is a bad idea according to my experience. I admit though that there are some cases when it is possible to add the checks in question, but I believe that would result in a very noisy code, while a simple ini config would do a much better service. Do the above examples and this reasoning make sense to you? Also, I'll improve the wording I used when describing the consequences. Regards, Máté
