Confirmed users
927
edits
Services/F1/Server/ServicesStatusDB: Difference between revisions
Jump to navigation
Jump to search
Services/F1/Server/ServicesStatusDB (view source)
Revision as of 14:45, 29 April 2011
, 29 April 2011→Rationale for the threshold
Tarek.ziade (talk | contribs) No edit summary |
Tarek.ziade (talk | contribs) |
||
| Line 108: | Line 108: | ||
When a third party service like Twitter gets down or is starting to be very slow, clients will retry to send to our servers more and more requests and our infrastructure will be overloaded and potentially unresponsive. | When a third party service like Twitter gets down or is starting to be very slow, clients will retry to send to our servers more and more requests and our infrastructure will be overloaded and potentially unresponsive. | ||
The goal of the threshold is to provide to every front web server a way to pre-emptively back-off for a limited time any new request to the services that are down in order to avoid piling up unnecessary work. This regulation will let our servers get back | The goal of the threshold is to provide to every front web server a way to pre-emptively back-off for a limited time any new request to the services that are down in order to avoid piling up unnecessary work and triggering infrastructure alarms. This regulation will let our servers get back to flow once Twitter is up again. | ||
== What happens without a threshold == | == What happens without a threshold == | ||