Every time the user scrolls in a grid with virtual scrolling, the grid asks for the total number of rows satisfying the filtering conditions. This causes the same exact query to be sent to the database multiple times. Instead cache this value and only ask for it if the filters change.
So with normal scrolling down the grid this will generate the following traffic to SQL:
Select Top 100, Skip 0 from Table where...
Select Count(*) from Table where (returns X number of rows)
Select Top 100, Skip 100 from Table where...
Select Count(*) from Table where (returns same X, exact same query)
Select Top 100, Skip 200 from Table where...
Select Count(*) from Table where (returns same X)
and so on
To see this open a copy of the grid with virtual scrolling:
https://dojo.telerik.com/eDImUhOV
Scroll the grid down:
In Developer Tools observer the result that is sent back to server includes the same:
__count: "830"
every time. In terms this will often generate a Select Count(*) being sent to the server in order to supply the answer for the current filters of the grid. An example when a Select count(*) is generated can be seen in your MVC wrappers, for example, where the toDataSourceResult() will cause this same query to repeatedly be sent to the database with every request for new data (use SQL Server Profiler or similiar to see the unnecessary queries). This is also true for your demo implemenations of the server code when used with Kendo UI.
For grids with large data sets, as is often used with virtual scrolling, this can be a slow query.
Instead of asking for the number of rows every time the grid is scrolled, only do so at inatialization and when the filtering conditions are changed (for example use a variable or an event to keep track of the dataSources filters changing).
If the program cannot assume that the same number of rows will be returned, then please implement a setting for developers that we can use to say that the data is not changing.
We look at historical data that are constant and with more than 100k rows, the Select count(*) puts an annecessary strain on the servers.
We could implement caching for this value, but instead the grid should not repetedly ask for the same value multiple times, instead of only when the filters change.