It would be great to get some feedback on this. I meant to put this in the WebGrid area, if anyone could move it over there I would appreciate it. Thanks!

Apologize for the delay in sending this.

I’m currently investigating the reported problem and going to forward this to WebGrid development team. I’ll keep you updated with any news or question we found.

Edited on August 8, 2012 11:20 PM
Reason: Update status and send sample to be reviewed

I tried to create a simple page based on the described issue. The detail is as follow (the sample page is enclosed as attachment):

• Using self-referencing hierarchical WebGrid
• One of the WebGrid’s column uses WebCombo
• WebCombo is bound to SqlDataSource with caching enabled

Before proceeding to the next stage of FlyPostBack investigation, could you please confirm whether the Grid and Combo structure in the sample is correct? For example: Is it correct that the grid uses self-reference+hierarchical structure?; Is it correct that the WebCombo controls are used as WebGrid’s editor in the root table of WebGrid? Or maybe the WebCombo controls are used as WebGrid’s editor in the child table of WebGrid?; etc.

This sample doesn’t use large dataset and two WebCombo controls yet. These will be applied once the control’s structure has been matched with the real scenario.

Please have the attached sample evaluated and let me know if there is anything that I miss in the sample. You may also modify the sample if needed.

For your information, I'm using WebGrid 7 and WebCombo 6.

Hi Yudi, I haven't had an opportunity to review your sample but I just wanted to clarify this example was for informational purposes only. We've been able to replicate the same basic issue in many places where the WebGrid contains a large, slow to process dataset. That goes for self-referencing hierarchy, grid with two levels, even standard one level grids with a lot of features and rows (per row processing, etc). The real issue is why does it slow down the combos? You should be able to replicate this with basically any grid setup where the data takes a noticeably long time to process. In my example the SQL call would take about .5 seconds and the time to process that data in the grid would be 8-10 seconds. We are using initialize datasource and a dataset, not linq or isdataset.

I assume someone on the tech side would be able to confirm my FlyPostBack finding as I assume this functionality would be well documented somewhere.

 

Thank you for the prompt reply.

I was unable to reproduce the reported problem with my simple sample. I enclosed the screenshot of my sample for reference.

Should you find anything that I missed in my sample, please feel free to let me know.

Unless I missing something the logging you’ve setup only reflects the initial page load and misses the FlyPostBack actions we’re attempting to measure. Logging to a text file in the background is a simple way to get around that UI limitation.

There really isn't any data in the Northwind DB that is conducive to this kind of loading delay. In order to emulate the kind of delays we are seeing update WebGrid1_Load to include this delay.

    protected void WebGrid1_Load(object sender, EventArgs e)
    {
        System.Threading.Thread.Sleep(10000);
        TextBox1.Text += "WebGrid1_Load: " + DateTime.Now.ToString("HH:mm:ss") + "\n";
    }

Now run the page and attempt to access a WebCombo. We’re seeing a 10 second delay when attempting to load the WebCombo’s data. Why would a delay in the WebGrid processing also produce a delay in the WebCombo’s processing? This is why we are trying to figure out if a FlyPostBack for a single control will trigger processing for all Intersoft controls on the page. The 10 second delay is extreme but I think this helps illustrate how 1 or 2 poorly performing controls can severely affect the performance of every control utilizing FlyPostBack on the page. We’ve seen this type of behaviour on many pages. The simple answer is to make sure every control loads very quickly. In some instances this isn’t possible. In some other instances the per-control performance might be adequate but the sheer number of controls on the page means the total delay for FlyPostBack still ends up being too large.

I hope I’ve made this clear. I think you can understand what a serious problem this presents to an application's performance. In a perfect world every control responds very quickly, but if for some reason it's necessary for one control to respond slowly that control should not slow down the performance of other controls on the page.

Thank you for the guidance by utilizing delay in OnLoad server side event of WebGrid to simulate process(es) during OnLoad server side event. I was able to reproduce the reported problem when user clicks the dropdown button of WebCombo (to have the result box window of WebCombo open).

I found an interesting topic in WebGrid’s documentation (start > All Programs > Intersoft WebUI Studio 2012 R1 > WebUI Studio for ASP.NET > WebGrid 8 > WebGrid 8 Documentation (Visual Studio 2010)), “Event sequence of server side events”. The article explains about the sequence of the events when they are executed during the first time the page is loaded. From this article, it is known that OnLoad server side event of WebGrid is executed during not on the FlyPostBack and on the FlyPostBack action.

When delay is added in OnLoad server side event of WebGrid using the following code snippet.

protected void WebGrid1_Load(object sender, EventArgs e)
{
    System.Threading.Thread.Sleep(20000);
    TextBox1.Text += "WebGrid1_Load: " + DateTime.Now.ToString("HH:mm:ss") + "\n";
}

The delay will be executed both in not on the FlyPostBack and on the FlyPostBack. When a breakpoint is placed in the first line of OnLoad server side event of WebGrid, the breakpoint will get hit when user clicks the dropdown button of WebCombo (FlyPostBack action). This will cause a delay in WebGrid also produce a delay in the WebCombo’s processing.

The WebGrid’s documentation said that OnInitializeDataSource server side event also executed during not on the FlyPostBack and on the FlyPostBack action. This event is used to place all codes related to the assignment of data source to the WebGrid component.

protected void WebGrid1_InitializeDataSource(object sender, ISNet.WebUI.WebGrid.DataSourceEventArgs e)
{
    dsNorthwind.CustomersDataTable dt = new dsNorthwind.CustomersDataTable();
    dsNorthwindTableAdapters.CustomersTableAdapter da = new dsNorthwindTableAdapters.CustomersTableAdapter();
    da.Fill(dt);
    e.DataSource = dt;
}

In most cases, the data source only needs to be assigned once. It means that we don’t need to re-assign the data source – when OnInitializeDataSource event is executed – during FlyPostBack action. I’d like to recommend you to put the data source assignment code under !IsPostBack condition.

protected void WebGrid1_InitializeDataSource(object sender, ISNet.WebUI.WebGrid.DataSourceEventArgs e)
{
    if (!IsPostBack)
    {
        dsNorthwind.CustomersDataTable dt = new dsNorthwind.CustomersDataTable();
        dsNorthwindTableAdapters.CustomersTableAdapter da = new dsNorthwindTableAdapters.CustomersTableAdapter();
        da.Fill(dt);
        e.DataSource = dt;
    }
}

The same thing can be applied to the delay-line in OnLoad event of WebGrid. If the process is not expected to be executed during on the FlyPostBack action, then we can simply move the code under !IsPostBack action.

protected void WebGrid1_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        System.Threading.Thread.Sleep(20000);
    }
    TextBox1.Text += "WebGrid1_Load: " + DateTime.Now.ToString("HH:mm:ss") + "\n";
}

For your information, I have checked that by moving the delay under !IsPostBack condition, I was no longer able to reproduce the delay problem when user clicks the dropdown button of WebCombo.

Please let me know if you have other thoughts or different result.

Thanks for the reply, Yudi. If you go back you'll see I actaully referenced the "Event sequence of server side events" page of the documentation in my original post. My concern is not the sequence, but that the sequence for each control is called every time there is a FlyPostBack for just one control. We actually wrap a lot of our code in a !Postback condition but in this case it doesn't help. We're not actually doing anything in WebGrid1_Load, it it just the standard processing the grid does. It just seems to reprocess what is already there even though we never directlt call this method or do anything inside it.

Adding the 10 second delay was a way to emulate the delay we're seeing in a slow grid/combo, but it's not a result of any code we're running ourselves, we don't actually call WebGrid1_Load anywhere, just referenced it as an example here as it seems to be the spot where the grid slows down. The problem is it isn't code we control so there is no way to skip it.

WebGrid_Load is described as "Indication of successfully preparation of data binding process and data populating in all rows". I don't understand why this would need to occur every time a WebCombo does a FlyPostBack. If there is some way to avoid it please let us know.

Hello Scott,

What Yudi tried to say is, "FlyPostBack action would trigger the same behaviour of server side event sequence same as FullPostBack". That's why during FlyPostBack action that event would also be triggered.

The question is, why WebCombo does flypostback that cause your issue. Once again, it might be called because the behaviour actually same as FullPostBack behaviour. That's why better to use !IsPostBack condition. 

However, we would like to investigate further about this issue. Please send us a simple runable sample that indicates WebCombo flypostback causing this issue. We tried to replicate this issue, but as you can see, we could not. In our previous sample, WebCombo itself did not cause flypostback action, right? There must be something that we need to know in your sample.

As far I know, using DataSource control should not trigger flypostback. Please help us to replicate the issue.

Regards,
Handy