That doesn't seem to quite make sense to have a large continuous grid when there is the option of paging.

Yes I'm doing that but it still seems to be taking quite a long time to load the data. The page itself renders in 3-5 seconds and the data appears 8 seconds later. The dataset is around 170k rows.

Here's the sample code:

CSHTML:

@using Infragistics.Web.Mvc;

@model IQueryable<CallHistoryModel>

@(

Html.Infragistics().Grid<CallHistoryModel>(Model).ID("grid1").PrimaryKey("CallID")

.AutoGenerateColumns(false)

.AutoGenerateLayouts(false)

.Width("100%")

.ResponseDataKey("Records")

.Columns(column =>

{

column.For(x => x.Date).HeaderText("Date");

column.For(x => x.Status).HeaderText("Status");

column.For(x => x.AgentName).HeaderText("Agent");

column.For(x => x.Number).HeaderText("Number");

column.For(x => x.CallID).Hidden(true);

}).Features(features =>

{

features.Filtering().Mode(FilterMode.Advanced);

features.Paging().Type(OpType.Remote).PageSize(50)

.ShowPageSizeDropDown(true).PageSizeList(new List<int> { 10, 15, 20, 50 })

.PrevPageLabelText(Resources.Test.GridButtonPrevious).NextPageLabelText(Resources.Test.GridButtonNext);

features.Sorting().Mode(SortingMode.Single);

features.Selection().MouseDragSelect(true).MultipleSelection(false);

features.GroupBy();

features.Resizing();

features.Hiding().ColumnSettings(settings=>{

settings.ColumnSetting().ColumnKey("CallID").AllowHiding(false);  

});

features.Tooltips().Visibility(TooltipsVisibility.Always);

}).Virtualization(false)

.GenerateCompactJSONResponse(false).DataSourceUrl(Url.Action("PagingGetData", "Calls"))

.JQueryTemplating(false)

.DataBind().Render()

)

Controller:

public ViewResult Index()

{

return View("Index");

}

[GridDataSourceAction]

public ActionResult PagingGetData(int page, int pageSize)

{

var ds = productRepo.GetAll();

return View("Index", ds);

}

Thanks for the sample solution file. I see the main difference is that you sorted with the primary key. I did that and the performance did go from 8-9 seconds to 1.5-2seconds for the data to render.

So I have tried to build indexes for the three fields i'm sorting, however that is still taking 5-6seconds to render. I actually did have it prepopulating the iqueryable before since I had a nullable date field and the grid doesn't like nullable datetime fields but that is another story. Prepopulating takes 3-5seconds to load the data so I guess that is the solution I'll go with for the time being. But it looks like I can speed up the other grids at least.

Thanks for your help.

Hello slinex,

As this matter seems to be related to an existing development issue, I have linked this case to the existing work item - 114943. The next step would be for our development team to provide more information regarding this scenario.

Your support ticket regarding this matter is CAS-94207-YF6KG3. Please feel free to contninue sending us any updates through this case.

Do not hesitate to contact me if you need more information.

I looked into the source code and got around the issue of the double querying for now.

But it looks like sorting and filtering are doing some strange things as well, see attached zip file for a screenshot of the requests that occur when sorting with a filter already in place. We filtered down 300k records down to 50 (took 5 seconds), and then did a sort which took 10 seconds to return the data. The last column is the duration in the screenshot.

Thanks.

Edit: After a day of trying to optimize the query in various ways, everything seems to be going smoothly even with the double querying.

Another quick update:

AutoGenerateLayouts is slated to be set to FALSE by default in the next Service Release so that along the applied fix from the RnD team only one data retrieval query will be executed.

The fix (and the change) will be included in the next Service Release which should be available somewhere around the middle of next month if all goes according to schedule.

Thank you for helping us drill down to the bottom of the problem and for your patience - hopefully the next SR will give you exactly the performance you're looking for.

Cheers,
Borislav 

Hi Borislav,

We already have that set to false and as I just checked from the sample you have on skydrive, that is also set to false.

Thanks.