Files
notifications-admin/app/assets/javascripts/updateContent.js

73 lines
1.7 KiB
JavaScript
Raw Normal View History

(function(global) {
"use strict";
2016-06-11 12:02:47 +01:00
var queues = {};
var dd = new global.diffDOM();
var defaultInterval = 2000;
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
var interval = 0;
var calculateBackoff = responseTime => parseInt(Math.max(
(250 * Math.sqrt(responseTime)) - 1000,
1000
));
var getRenderer = $component => response => dd.apply(
$component.get(0),
dd.diff($component.get(0), $(response[$component.data('key')]).get(0))
);
2016-06-11 12:02:47 +01:00
var getQueue = resource => (
queues[resource] = queues[resource] || []
);
var flushQueue = function(queue, response) {
while(queue.length) queue.shift()(response);
};
var clearQueue = queue => (queue.length = 0);
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
var poll = function(renderer, resource, queue, form) {
let startTime = Date.now();
if (document.visibilityState !== "hidden" && queue.push(renderer) === 1) $.ajax(
resource,
{
'method': form ? 'post' : 'get',
'data': form ? $('#' + form).serialize() : {}
}
).done(
response => {
flushQueue(queue, response);
if (response.stop === 1) {
poll = function(){};
}
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
interval = calculateBackoff(Date.now() - startTime);
}
).fail(
() => poll = function(){}
2016-06-11 12:02:47 +01:00
);
setTimeout(
() => poll.apply(window, arguments), interval
2016-06-11 12:02:47 +01:00
);
};
global.GOVUK.Modules.UpdateContent = function() {
this.start = component => setTimeout(
() => poll(
getRenderer($(component)),
$(component).data('resource'),
getQueue($(component).data('resource')),
$(component).data('form')
),
defaultInterval
2016-06-11 12:02:47 +01:00
);
};
Delay AJAX calls if the server is slow to respond By default our AJAX calls were 2 seconds. Then they were 5 seconds because someone reckoned 2 seconds was putting too much load on the system. Then we made them 10 seconds while we were having an incident. Then we made them 20 seconds for the heaviest pages, but back to 5 seconds or 2 seconds for the rest of the pages. This is not a good situation because: - it slows all services down equally, no matter how much traffic they have, or which features they have switched on - it slows everything down by the same amount, no matter how much load the platform is under - the values are set based on our worst performance, until we manually remember to switch them back - we spend time during incidents deploying changes to slow down the dashboard refresh time because it’s a nothing-to-lose change that might relieve some symptoms, when we could be spending time digging into the underlying cause This pull request makes the Javascript smarter about how long it waits until it makes another AJAX call. It bases the delay on how long the server takes to respond (as a proxy for how much load the server is under). It’s based on the square root of the response time, so is more sensitive to slow downs early on, and less sensitive to slow downs later on. This helps us give a more pronounced difference in delay between an AJAX call that is fast (for example the page for a single notification) and one that is slow (for example a dashboard for a service with lots of traffic). *Some examples of what this would mean for various pages* Page | Response time | Wait until next AJAX call ---|---|--- Check a reply to address | 130ms | 1,850ms Brand new service dashboard | 229ms | 2,783ms HM Passport Office dashboard | 634ms | 5,294ms NHS Coronavirus Service dashboard | 779ms | 5,977ms _Example of the kind of slowness we’ve seen during an incident_ | 6,000ms | 18,364ms GOV.UK email dashboard | `HTTP 504` | 😬
2020-04-08 17:55:53 +01:00
global.GOVUK.Modules.UpdateContent.calculateBackoff = calculateBackoff;
})(window);