In a data-driven web application, I have several razor views which contain tables that were created using tabulator, and are updated using self calling ajax functions on an interval. In most of the views, the number of tables is no more than three, and network performance and lag between updates is fairly quick. I am currently creating a view that houses over six tables, and am seeing an uptick in dropped request, stagnation in the data, and general slowness that seems to be directly attributable to the increased number of concurrent requests on the page. I am by no means a JavaScript or MVC expert, and am trying to investigate whether my code is just inefficient, or if the approach itself is wrong.
Essentially, each tabulator table has an ajax function that will hit an endpoint at the MVC layers, which routes to a WebApi2 endpoint to retrieve the latest data, and finally, use one of tabulators loading functions to load the data into the table. The data end is SQL using Entity Framework. I have tried several implementations built around this process, but below is the approach I am currently using.
// Function for waiting in between calls
function sleep(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
// Function for getting data from endpoint
async function fetch() {
$.ajax({
type: "GET",
url: www.mydata.com,
}).done(async function (data) {
// Tabulator function for replacing existing data with new
table.replaceData(data);
await sleep(10000);
fetch();
}).fail(async function () {
await sleep(10000);
fetch();
})
}
// Call the fetch function the first time, self calls afterwards
fetch();
Each table in the view runs a version of the code snippet above. I added the sleep functions, hoping to introduce some delay between request. It is also worth pointing out that at the ASP.NET MVC layer, there is also increased congestion. It takes longer to service request made by the user to create a new entity, due to the all the other request flying back and forth.