GridView + ObjectDataSource issue - equally bad performance for large and small result sets

Question

I was called to work on an older .NET legacy web app recently. The performance had recently fallen quite sub-par, as the amount of data in the system had quadrupled. Had been fine for the previous 2 years.

It was using a .xsd file to talk to a stored procedure that narrowed the results sufficiently (though no paging) and feeding them into a GridView via an ObjectDataSource.

The part I can't get my head around, is it was taking a about 7 seconds to load for 1 result, 140 or 1200. It took a split second for 0 result cases. (GridView is handling the pagination)

Using SQL profiler, we were able to see that the query was taking 6.9 seconds. Running the same query with the same params took 100ms in SQL Management Studio. I changed parameters around to ensure it wasn't just a cached result. The long wait time is reliably reproducible.

I'm aware that implementing paging would need to be done here, but for now I'm just retrospectively trying to find an explanation behind why the page is performing equally poorly for small and large sets...

(The GridView's 'simple' display is fine for their needs - no need to control the HTML)

Answer 1

We've have the very same issue:

1. Check if your statistics are up to date:

    SELECT 
        ObjectName = Object_Name(ind.object_id),
        IndexName = ind.name,
        StatisticsDate = STATS_DATE(ind.object_id, ind.index_id)
    FROM SYS.INDEXES ind
    order by STATS_DATE(ind.object_id, ind.index_id) desc

2. Drop the SQL server cache:

    DBCC DROPCLEANBUFFERS
    DBCC FREEPROCCACHE

3. If neither helps, you can try to enforce the SSMS query plan with hints like "inner LOOP join" and "with (index=...)".

Answer 2

You could try looking at the execution plan and type of parameters that are sent from your application. For example, if you application is passing a nvarchar to compare against a varchar column it could cause issues. http://weblogs.sqlteam.com/tarad/archive/2007/11/16/60408.aspx