This topic will discuss the concept of FlyPostback architecture and how to improve its performance in Internet-zone web applications.
OnTheFly-Postback Introduction
Since introduced in WebCombo.NET V1.0 back in 2002, the FlyPostBack architecture developed by Intersoft Solutions have been significantly enhanced from time to time, until the release of WebUI.NET Framework 2.0.Today we have seen the trend of AJAX or callback in ASP.NET 2.0, component vendors are now focusing to provide similar functionality to their products. Many of our customers have asked whether AJAX is something similar to our OnTheFly-Postback architecture, or is it something new. In this article, I'll try to explore some comparison of concepts and functionalities between our architecture and the others.
FlyPostback concepts and features
As you may have already know, AJAX is not a technology, it is an approach. It basically means that the approach used Asynchronous Javascript and XML to perform communications between client and server by using XmlHttp request which is supported by most modern browsers. So the whole idea is XmlHttp request. However, XmlHttp is not a new thing, it has been existed since 2001 when Microsoft introduced Internet Explorer 5.0. The point is, it is just getting attention and becomes popular recently as Gecko and Opera started to support it.
FlyPostback architecture is not just about using XmlHttp request to perform out-of-band callbacks to server and then obtain the response from server. FlyPostback is kind of framework or engine which built on the top of XmlHttp plus our own features implementation to bring a new standards for our ASP.NET components product line.
To clearly understand the concept of FlyPostback architecture, I've listed some of the unique features below which can't be accomplished by other similar XmlHttp-based approach:
- Full ASP.NET Framework and Page support
It means that FlyPostback supports any kind of ASP.NET Framework scenarios and page life cycle. For example, you can use inline <% %> server side codes in the aspx and the FlyPostback can still perform perfectly. The FlyPostback can work seamlessly and do not require you to configure HttpModule or any changes in your web configuration file.
- ViewState restoration.
Unlike other XmlHttp approach, FlyPostback automatically restores the viewstate of all server controls available in the Page. This enables developers to be able to obtain other controls' value while in the FlyPostback context.
- Controls state and input parameters
All products that built on the top of FlyPostback architecture such as WebGrid.NET Enterprise and WebCombo.NET will have its state automatically maintained by the FlyPostback architecture. This is very crucial and important for developers in order to extend the products functionalities to fit their custom logics. For example, I can get the selected object of WebGrid1 instance while the current context of FlyPostback is initiated by WebGrid2. I will then be able to populate data based on the selection made in WebGrid1. Remember that we're on FlyPostback context, not a full page postback.
I can also add custom parameters and send it along with the FlyPostback request, for example, adding additional data or flag during updating row. It can be easily done by using AddInput() method which is applicable to all products that supported FlyPostback.
Improving FlyPostback performance
Now, the interesting part of this article is how we can improve the performance of FlyPostback. By understanding the concepts and features above, we clearly understand that FlyPostback architecture posted quite a lot of data during the request. There is no significant performance issues when the application is running in intranet or extranet zone, however when utilized in public website -- and especially when end users used narrow-bandwith, it is noticable that the FlyPostback request is a bit slow in the response.
In WebUI.NET Framework 2.0, we have developed a few properties which developers can configure in order to turn off specific features of FlyPostback in case they did not utilize it in their applications. Many of our customers still have not aware of these capabilities and hopefully with this article, they would be able to set best configuration to use for their applications.
Following are the list of features which may be turned off to improve the response time of FlyPostback request. These settings can be found in FlyPostbackSettings object in control's instance:
- PostViewState.
The value is True by default. When set to true, FlyPostback will automatically restores the viewstate of all server controls available in the page. So, if you do not access other controls' properties in FlyPostback context, you can safely set this property to False. This will give significant improvement especially when the viewstate of the Page is large.
- PostHiddenFields.
The default value is True. If you do not access hidden fields on page load or in FlyPostback requests, you can safely turn off this feature by setting it to False.
- PostInputControls.
The default value is False. This feature enables you to get the latest value for the html input fields in the FlyPostback context. If you do not need to access other controls' value (such as TextBox's value), then you should have this property's value remain False.
- PostControlState.
This is a new property added in WebUI.NET Framework Build 12. The default value is True. In previous build, you have to turn on PostHiddenFields in order for the FlyPostback's control to maintain its state properly during request. However, since PostHiddenFields also send out other controls' hidden fields, it becomes ineffective and causing slower response time due to larger post data. Now, you can safely turn off PostHiddenFields and leaving this property value to True.
The control state is the most interesting point in the features above since it needs to be configured properly, otherwise client interactions will react improperly. The best value for this configuration is based on the nature of product and which features are enabled. For example, in WebCombo, you may turn off this feature since WebCombo did not have as much client interaction as in WebGrid. As for WebGrid, this feature is recommended to be turned on (by default). There are however, certain scenarios where you can safely turn off this feature in WebGrid. For instance, if your Grid instance does not require clientside user interactions features such as column moving, resizing, sorting, filtering or others, then you can safely turn off this feature. These scenarios are suitable for application which require only hierarchical load on demand Grid mode or self hierarchical load on demand feature.
By summary, if you do not access other controls' value or properties, here's the most recommended FlyPostBackSettings:
For WebCombo.NET 3.0:
- PostViewState = False
- PostHiddenFields = False
- PostInputControls = False
- PostControlState = False
For WebGrid.NET Enterprise 4.0:
- PostViewState=False
- PostHiddenFields=False
- PostInputControls=False
- PostControlState=True
With above configurations, you'll get a significant response time improvement of every FlyPostback requests by at least 60%. Thus, if previously it needs 3 seconds to load WebCombo during dropdown, you'll now get the results in 1 or 1.5 seconds. Again, note that the context of this article is using narrow-bandwith protocols such as dialup
Conclusion
As a proof of concept, we have also modified our live samples to use minimal features since they are not utilized in common basic scenarios. For WebCombo, please take a look and play with the "Basic" sample. For WebGrid, play with the "Hierarchical" sample. Then, compare with other samples. You'll be able to see significant response time improvement in both samples mentioned above.As a final note, you would need to update to latest build for the framework and all products in order to take advantage of some of the new functionalities.