60 seconds is considered a long time… most of our internal API calls have much shorter timeouts (5, 15 or 30 seconds), and we like to avoid hitting those limits! There are some infrastructure components (reverse proxy layer) which impose their own 60 second limit on pending requests – we rarely see this as a problem, and if it occurs it’s usually indicative of another behavior or problem (see concurrent requests spiel above). If we assume that the timeout applies to “time-to-first-byte”, and does not cover the time required to transfer a large response, then 30 seconds should be sufficient. The known slow methods (get all projects/at-status) do not scale indefinitely – and it’s when we see project lists of 10s of thousands of projects that the internal 60s limit can be reached – usually a different pattern is the answer… The same APIs are used to drive our web UI, and as you might imagine, 60s is an eternity to a user watching a “spinner”…
60 seconds is considered a long time… most of our internal API calls have much shorter timeouts (5, 15 or 30 seconds), and we like to avoid hitting those limits! There are some infrastructure components (reverse proxy layer) which impose their own 60 second limit on pending requests – we rarely see this as a problem, and if it occurs it’s usually indicative of another behavior or problem (see concurrent requests spiel above). If we assume that the timeout applies to “time-to-first-byte”, and does not cover the time required to transfer a large response, then 30 seconds should be sufficient. The known slow methods (get all projects/at-status) do not scale indefinitely – and it’s when we see project lists of 10s of thousands of projects that the internal 60s limit can be reached – usually a different pattern is the answer… The same APIs are used to drive our web UI, and as you might imagine, 60s is an eternity to a user watching a “spinner”…
Translate
