Intersoft Community - WebDesktop - Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

handy@intersoftpt.com — Wed, 22 Aug 2012 21:26:58 GMT

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

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

sfrench@sierradata.com — Thu, 16 Aug 2012 14:53:18 GMT

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.

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

yudi — Thu, 16 Aug 2012 04:30:41 GMT

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.

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

sfrench@sierradata.com — Tue, 14 Aug 2012 17:41:15 GMT

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.

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

yudi — Sun, 12 Aug 2012 21:20:47 GMT

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.

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

sfrench@sierradata.com — Thu, 09 Aug 2012 19:48:58 GMT

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.

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

yudi — Tue, 07 Aug 2012 22:20:51 GMT

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.

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

sfrench@sierradata.com — Tue, 07 Aug 2012 13:25:30 GMT

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!

Is there any differentiation between WebGrid FlyPostback and WebCombo FlyPostBack?

sfrench@sierradata.com — Fri, 03 Aug 2012 15:01:55 GMT

We have a WebGrid that is setup with a self referencing hierarchy dataset. The dataset can get very large, in some instances over 3,000 records. There are two columns in this grid that use WebCombos bound to SqlDataSources with caching enabled. We've noticed a direct correlation between the performance on WebCombos on the page and the size of the dataset in the WebGrid. When the grid only has a few record the WebCombos can FlyPostBack very quickly and return results. When the dataset in the grid is very large the WebCombos perform very slowly, taking nearly ten seconds to return any data.

Trying to figure out where the bottleneck is we've done some tracking and logging. Our WebGrid contained about 3000 records and both WebCombos contained around 15 records. We started with Fiddler to track the actual information sent in the request and information received in the response when dropping down the WebCombo to bring up the list of items. The amount of data sent in the request is very small and the amount of data received is also very small. There seems to be a slow down on the server side processing even though we are using caching for the WebCombo's datasource and can confirm using the SQL profiler that there is no additional call to the database after the intial load. With this information in hand we decided to start looking into the server side events. We inserted a large number or logging points across pretty much every Page, WebGrid, and WebCombo server side event. What we found were a lot of events being called that we did not expect. There are a lot of WebGrid events being called (this seems to coincide with the information found in the support docs here: "Features and Concepts >> Events >> Event sequence of server side events"). We've highlighted the slowdown area below.

List of server side events called when a WebCombo sends a FlyPostBack request to bring up drop down results (Minute:Second:Millisecond format):

Page_PreInt: 14:32:544WebGrid1_PreInitialize: 14:32:549
WebGrid1_Init: 14:32:551
WebCombo1_PreInitialize: 14:32:554
WebCombo1_Init: 14:32:557
Page_Init: 14:32:571
Page_InitComplete: 14:32:572
Page_PreLoad: 14:32:589
Page_Load: 14:32:591
WebGrid1_InitializeLayout: 14:32:594
WebGrid1_PrepareDataBinding: 14:32:596
WebGrid1_CustomSort: 14:32:598
WebGrid1_OnCustomSort: 14:32:599
WebGrid1_Load: 14:41:142
WebCombo1_InitializeLayout: 14:41:155
Page_LoadComplete: 14:41:158
Page_PreRender: 14:41:160
WebCombo1_InitializePostBack: 14:41:162
WebCombo1_PrepareDataBinding: 14:41:163
WebCombo1_InitializeRow: 14:41:165
WebCombo1_InitializeRow: 14:41:191
WebCombo1_Unload: 14:41:192
WebGrid1_Unload: 14:41:196
Page_Unload: 14:41:197

We lose almost 9 seconds around the WebGrid1_Load call. We assume this is directly related to some kind of WebGrid processing as it will be much faster if there are fewer rows in the table.

That leads us to our question... is there a differentiation between the WebCombo FlyPostBack and the WebGrid FlyPostBack? Meaning when a WebCombo makes a FlyPostBack is there any reason why the WebGrid's events would/should also fire? The page log above would lead us to believe there is no separation and events for both the WebGrid and WebCombo will always fire on FlyPostBack. Is there any way to get around this? Obviously in this case with a large/complicated grid we would prefer a separation between these type of calls. We've already gone through pretty much every other performance boosting option listed (include the FlyPostBackSettings, XMLCompression, ViewStateStorage, etc) so getting to the bottom of this specific situation is very important to us.

EDIT: Follow up question... in the situation where we use multiple WebCombos or multiple WebGrids on the same page what would prevent any single FlyPostBack call from initializing these same events for every control on the page? For example with two WebGrids on the same page, every time a FlyPostBack call is made would all of the associated events for WebGrid1, WebGrid2 and all WebCombos be called? This would help explain performance issues we've run into in the past. I think our assumption always was that any specific control capable of making a FlyPostBack call would only cause events directly related to that control's current FlyPostBack operation to fire. This doesn't seem to be the case.