Latest Development Blogs
Forum Topics Post
Browse By Tag
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)
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.
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.
assume someone on the tech side would be able to confirm my FlyPostBack finding
as I assume this functionality would be well documented somewhere.
Bernard, does the grid auto-detect/decide which datatype it's going to use for a column? I tried setting the DataType to "System.String" and even set ColumnType to "Text" but it didn't seem to help.
We weren't able to replicate in the samples either,
maybe it has to do with SQL server or maybe some setting in the
Scheduler we missed. I've created a new sample page and stripped out all
of our custom code. We still get the error but it's slighly different
now. This probably has more to do with pointing to data that has changed
for the resources and not the changes in the page itself.
Here's the new version. The sample files have been attached.
I've put together a quick sample as this error has been very easy to replicate. Drop the four aspx files into a project running WebDesktop 308. Open the sample form page and click the test button. It should look like good.jpg. Do the same for a project running 324 and you will get something similar to bad.jpg. I can't confirm with 334 until we have a way to access that version.
Is there anyway to access this update without a new installation? We have 2009 R1 SP1 installed and have kept up to date using the Update Manager.
For this page we are using InitializeDataSource and there is a large amount of code specific to our own custom DAL and security settings in this sub. Converting this page to use LINQ and a WebService would require a huge development effort that we did not anticipate. Do I understand the situation correctly? Is the only way to get Group Row Paging to work using LINQ/WebService as the datasource?
The blog linked above has 4 main sections. "Preload Group Totals", "Group Row Paging", "Virtual Load Support For Web & WCF Service", and "WebGrid LINQ Data Provider". We are only interested in the first two at the moment. "Preload Group Totals" looks to be working when following the directions. "Group Row Paging" is what we are talking about. All we did was add the GroupRowPageSize="200" tag into the ClientBindingSettings area. I don't see any other instructions to get this working.
Discover WebUI Studio® 2012
Get Started with WebUI Studio®
WebUI Studio® Edition
For ASP.NET Development
For Silverlight Development
For WPF Development
Learn More About ClientUI