In my post last month, I mentioned about data optimization feature in Crosslight 4 which could greatly improve the overall performance and experience of your Crosslight apps. So here we are, this week’s post will feature this optimization feature, and you will learn how to apply it to your apps. Read on.

In Crosslight 4, we shipped a lot of new stunning components like charting, barcode reader, dialog presenters and much more. But that’s not all. We also pay a lot of attention on small and unseen areas such as the data framework, logging, and view projection. In fact, no feature is too small. For instance, the new extensible filters in RestClient enable you to add request and response compression and make your apps work 75% faster, particularly if you’re building enterprise apps that sync relatively large data. Let’s see how it works.

Adding a new request or response filter to the RestClient is extremely easy, thanks to the new, intuitive API. Here’s how:

this.GetService<IActivatorService>().Register<IRestClient>(
c =>
{
    RestClient restClient = new RestClient(appSettings.RestServiceUrl);
    restClient.AddRequestFilter(new GZipRequestFilter());
    restClient.AddResponseFilter(new GZipResponseFilter());

    return restClient;
});

If you’re using Crosslight App Framework, you can simply add the code in the AppService class where all container registrations are defined. The Rest client in the entire app will automatically have the filters applied.

Since the filter is provided as interface, you can plug any capabilities you desire, whether it is a compression filter, an encryption filter, etc. In this case, let’s not reinvent the wheel. We’ll just grab an existing Microsoft.Bcl.Compression library from NuGet. Here’s an example how we can extend a third-party library to work with our filter interface:

public class GZipRequestFilter : GZipFilter, IRestRequestFilter
{
    public void Filter(IRestRequest request)
    {
        request.AddHeader("Accept-Encoding", "gzip, deflate");
        Parameter requestBody = request.Parameters.Where(o => o.Type == RequestParameterType.RequestBody).FirstOrDefault();

        if (requestBody != null)
        {
            request.AddHeader("Content-Encoding", "gzip");
            requestBody.Value = this.Compress(requestBody.Value.ToString());
        }
    }
}

public class GZipResponseFilter : GZipFilter, IRestResponseFilter
{
    public void Filter(IRestResponse response)
    {
        Parameter contentEncoding = response.Headers.Where(o => o.Name == "Content-Encoding").FirstOrDefault();

        if (contentEncoding != null && contentEncoding.Value.ToString().ToLowerInvariant() == "gzip")
            response.Content = this.Decompress(response.RawBytes);
    }
}

As seen above, we can just extend an existing class, say, the GZipFilter class, then implement the IRestRequestFilter and IRestResponseFilter. Both interfaces require an implementation of Filter method, that’s where you perform the actual logic of the filter.

On the server-side, if you’re using IIS for the web server, then you can just enable the dynamic compression feature. Afterward, the WebAPI response will be automatically compressed.

One thing to note though, WebAPI doesn’t automatically recognize the compressed requests. Fortunately, Microsoft already has a NuGet package for that. So we’ll just grab the ASP.NET WebAPI Compression Support, then add the following code to the WebAPI config class.

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        // Web API configuration and services
        config.MessageHandlers.Insert(0, new ServerCompressionHandler(new GZipCompressor(), new DeflateCompressor()));
    }
}

Pretty easy, right?

Based on performance test on one of the apps we built for our enterprise client, enabling the compression filters speed up our apps performance by nearly 4x. Previously, in certain case, the app took 9 minutes to synchronize a thousand of data over the Edge connection. With compression enabled, the app only took only 2 minutes to sync the same set of data over Edge, and only a few seconds over Wifi. The user couldn’t be happier. So we hope you can do the same too, your users will thank you so much.

To see the feature in action, pull the sample from our Git, and play around with it. The feature is also fully documented, which you can find here. Happy optimizing!

Best,
Jimmy

Apparently, Internet Explorer has a serious flaw in performance when a script is trying to add styles programmatically while loading, and at the same time when layouting is performed by other scripts.

To eliminate the performance issue, all styles in WebMenuBar should be defined as CssClass instead of using server-side predefined styles.

For comparison, I have attached two samples (with and without CssClass). Run the samples and compare the performance difference between them.

Note: This technique also works on standalone WebToolBar which causes the same issue.

Regards,
Handy.
Support Engineer.

In the following section, we’ll learn how client paging work specifically in Timeline View (the other views will be discussed in future blog posts). We introduce several client paging modes which can help improving overall application response based on your scenarios.

Let’s start by enabling the client paging in Timeline view. We’ve made it extremely easy to use, so that you can enable the feature by simply setting EnableClientPaging property to true. The property can be found in ViewSettings, then expand TimelineView property.

After enabling the client paging, the next step is to choose the client paging mode that is more suitable to your application scenario. WebScheduler 3 introduces three client paging mode to choose from:

1. Paging based on number of events
   Called EventPageSize mode, this paging mode restricts the numbers of event displayed in each Timeline cell. If the total number of events exceeds the value of the EventPageSize property, an arrow indicator will appear notifying that more events are available. Click on the arrow indicator to reveal the complete events in the Timeline cell.To use this paging mode, simply set the ClientPagingMode property to EventPageSize.

   
   

2. Paging based on screen viewport
   Called ViewPort, this paging mode will render all events based on the currently visible viewport. This means that even if you have hundreds of resources, WebScheduler will present your events in consistently fast performance. When scrolled down, WebScheduler seamlessly render the complete events of the new visible viewport. As the result, this advanced paging mode significantly improves overall responsiveness and user experiences.
   You should consider using this paging mode if you have fairly large number of resources bound to your WebScheduler.

   To activate this mode, set the ClientPagingMode property to ViewPort.

   

   

3. The combination of both event size and viewport paging
   This mode combines the best of both EventPageSize and ViewPort client paging for the most efficient event rendering. With this mode, the events will be rendered based on the visible viewport and also be restricted based on the number of allowed events. This mode is best used for applications with considerably large number of resources and events bound to WebScheduler.

   To enable this mode, set ClientPagingMode property to Both.

   

At this point, you should have learnt the new key features in WebScheduler 3 that elegantly address critical performance limitations in web-based scheduling application. So if you’ve got large, enterprise data to be presented in scheduling interface, go ahead, download and try WebScheduler 3, and impress your users big time!

Last but not least, you can find out more information on WebScheduler 3’s new features here and the live demos here. For questions and feedback, please drop by our forum.

Happy scheduling!

Warm Regards,
Budianto Muliawan.

If you’re building a large scale, enterprise resources planning application that involve thousands of resources and events in a single month view alone, you would have quickly realizing serious performance issues during the development process. In this post, I’ll share some insights on the common pitfalls and bottleneck in performance, and how our latest scheduling component completely address them in elegant ways.

The Challenges

There are at least 4 factors that would lead to performance issue in most enterprise applications and specifically in scheduling applications.

1. Huge data transfer size.Take a look at our recent case study on a car rental application. The car rental could have over 3,000 events made in a month. In most scheduling component in the market, all data will be retrieved at once in the page load. That transmits over 2MB of data sent over the cloud which translates to 6-7 seconds waiting even on a broadband connection.
2. Long rendering process.With rich user interface possible nowadays, web developers often forgot that a web application is not a desktop application. The nature of web application still have several common constraints such as the amount of elements which are considerably good on a page. In the case of enterprise application, serious performance bottleneck could arise due to the massive objects creation and long rendering process which could take 8-10 seconds for a page bound to several thousands of data.
3. Heavy backend query.
   
   Most datasource controls introduced in ASP.NET don’t enable paging by default. While it may not be a significant issue in relatively smaller application, it could be a great showstopper for enterprise application with millions to billions worth of data. Non-optimized database query itself could cause performance issues in at least three ways: the heavier workload and resources required to compute the query, huge data transmission from the backend to business layer and ultimately yielding more extensive operation in the UI layer.
4. Poor data processing.Specifically for a scheduling component, poor data processing logic is often a factor that causes performance issue. Scheduler is a unique component that process data in several phases, such as resources categorizing, data grouping and more. Thus, improper data processing logic could result in longer time required to compute the final shape of the data required by the scheduler interface.

The Solution

WebScheduler 3 is strongly focused on addressing performance issues and improving application scalability at the same time. One of the our key goals is to achieve a consistent performance while loading a scheduler bound to thousands of data – for example, 1-2 seconds regardless of the data size.

ViewPort paging was born as the result of our extensive R&D. It is specifically designed for Timeline View (Gantt Chart Style) which makes more sense due to its layout nature that display huge data in a single resource. To completely eliminate the key performance issues discussed above, we also invented three more innovative features that work in conjunction with ViewPort paging. They are event-based client paging, server paging and efficient data categorizing process.

Instead of loading huge data on every data request, ViewPort paging works by loading only a small chunk of data in the first load which seamlessly fills the data based on the available real screen estate. It will load the rest of data on demand as users scroll downward. Also keep in mind that ViewPort intelligently saves a cache of loaded data, so it won’t retrieve the same data twice. The result is maximum performance, increased responsiveness and extremely smooth user experiences.

The ViewPort implementation doesn’t merely handle data paging process, it  also takes account every single feature that associated to it, say, new event creation, recurrence editing, and data drilling. It also flawlessly handles a vast array of complex scenarios such as drag-drop operation across resources and time, multiple selections, views switching, and more.

In addition to ViewPort paging, WebScheduler 3 also implements smart client paging to other views including day view, week view,  split view and all day area view. We also add client paging interface to the details box in month view.

All in all, WebScheduler 3 successfully delivers on its key objectives to redefine a new standard in performance for enterprise-class usage and improving user experiences at the same time. The following chart shows the performance benchmark tested in various browsers.

Our engineers will soon post more coverage on other new exciting features such as customizable time intervals, visible hours, disabled time and more. So stay tuned!

As the word said, pictures worth a million words. Videos worth a zillion. Watch the video below and see the new performance improvements in WebScheduler 3.

You can also experience it yourself by trying our new Blitz rent-a-car reference sample available online.

Learn More

WebScheduler 3 is released – download your 30-day trial copy today to experience the exciting new features for yourself.

More resources on WebScheduler 3 can be found in the following links:

Overview

Performance Benchmark and Comparison

Powerful Client Paging Capability

Top New Features

Top 10 New Features Video

Live Demos

All the best,
Jimmy.

In this research, I’m running on Windows 7 Professional, IIS 7.5, Visual Studio 2008 SP1, and HttpWatch Professional installed with WebGrid Enterprise’s samples.

The Challenges

Using the Enterprise sample with all features enabled, the total size of client resources — including javascript and styles —  is around 1.2 mb with all compression disabled. This would be a potential issue for users in remote area with slower internet connection.

Without compression, the client resources size is around 1.2 mb.

The Solutions

SmartWebResources’ Compression Technology

SmartWebResourcesâ„¢ technology not only introduces unique architecture for hassle-free deployment, it also comes with built-in compression feature with a reasonable result. Simply put the key below in your web.config to enable the compression:

<add key="ISNet.WebUI.ISRes_Compressed" value="true" />

The result will look like the screenshot below.

The SmartWebResources’ squeezes client resources to 680 kb, saves roughly 60%.

IIS 7 Dynamic Compression

The latest IIS now offers easy customizability in more user friendly format. Unlike its previous version, compression can be enabled without having to edit a certain .config file. You can enable/disable the compression directly in the IIS Manager.

If you wish to learn more about IIS 7’s compression, please click here.

The default compression level is 7. The compression level in IIS is, fortunately, customizable although you won’t find this setting anywhere else in the documentation.

To change the compression level in IIS 7, run the following syntax from command line:

[WinDir]System32inetsrvappcmd set config /section:httpCompression
/[name='gzip'].staticCompressionLevel:[CompressionLevel]

The acceptable value for compression level is 1 – 10. Setting the compression level to 10 will instruct the IIS to use the best compression quality which produces the smallest output. While it’s great to be able to compact the client resources and deliver very small output to client, it requires a more powerful server for heavier processing and overhead.

In my opinion, the default level is the best option for web applications that run on moderate servers. It doesn’t compress as much as level 9 or 10, but offer less overhead on the server.

IIS 7 Compression (level 7)

Conclusion

If you have the direct access to the deployment server which used IIS 7, IIS compression is definitely the best solution to keep your applications speedy with low client resources footprint. However, if you’re hosting your web applications in a shared server, or if you don’t use IIS 7 yet, then SmartWebResources compression is your best choice. It may not compress as much as IIS, but it still offers reasonable compression result with much lower server overhead.

#1 – Why not using homegrown table for best speed?

Unfortunately, there’s no remedy when it comes to binding large data table using basic technique. As I mentioned previously, a single .NET’s Fill method alone already takes 20 seconds to fill 350k data into the dataset. Not to mention the time to populate and dispatch each row into the UI, it will take at least 25 seconds until rendering.

If you have a large datatable, you can give it a spin using the following sample:

<asp:GridView ID=”GridView1″ runat=”server” AllowPaging=”True” AllowSorting=”True” AutoGenerateColumns=”False” DataKeyNames=”ID” DataSourceID=”SqlDataSource1″>
   <Columns>
        […Columns]
   </Columns>
</asp:GridView>

If the above sample can be bound to 350k data in less than 20 seconds, I’m interested to learn further.

#2 – I guess we can use SqlDataSource with DataReader mode and bind it to GridView.

Unfortunately, DataReader mode in SqlDataSource won’t work with Paging and the rest of databound features. So, SqlDataSource is totally unviable.

#3 – How about ObjectDataSource, or other built-in datasource controls that come with ASP.NET?

ObjectDataSource does support paging, but it falls into the same bottleneck as it used DataAdapter to fetch the results into a DataSet. The pagination is done at server-side control level and not at database level, and hence, it will result into the same 20 seconds performance hit.

So at this time, none of the built-in datasource controls (or the GridView) can bound to a large data table efficiently.

#4 – Isn’t it inefficient to bound to such a large table? I think in real world scenarios, you should have a predefined filter for data fetching.

Good shot. Although our Grid supports large table binding, we often recommend customers to load and retrieve data efficiently by either using predefined filter or asked user to enter some search criteria before requesting data. Best design & pattern in application architecture is always our first priority and suggestion.

However, the large table binding is unavoidable in several enterprise scenarios. For a quick real-world scenario, administrator often need to browse a table of their Sql database via Web in order to maintain the data records (or perhaps updating records). As business growth, the table might contain more records. In this situation, if the deployed data grid is not able to display the data in acceptable timing, the administrator will waste his entire day in waiting the Web page to response.

For us, it’s extremely important to support such enterprise scenarios (as we utilized it in our own internal application as well).

Conclusion

Performance is always a hot topic in software industry, especially in reusable component industry as it becomes foundation and backbone of many enterprises Web application. Some products are good in styles, but not performance. Some are good in performance, but not styles.

WebGrid.NET Enterprise is striving to deliver both the best user experience and styles, and performance.

In addition to the measurement factors that I used in my initial post, there are several more important points that worth mentioned.

• Database agnostics. Unlike competing products, WebGrid supports large data binding to any kind of database through ISDataSource control. You can bind to Sql Server, Access, Oracle and even your own custom object collection.
• Bare-metal architecture and elegant binding approach. Many developers end up with “tricky workaround” to achieve faster results. While this may work, it is not quite reusable in other pages, as many codes are involved in the page’s code behind. ISDataSource embraces an elegant and professional approach, which works consistently with the entire reusability concept that it introduced.Â
  Â
  Surprisingly, the sample that I mentioned in the previous post doesn’t contain any single line of codes related to the databinding or data retrieval in the page’s code behind. The Webform is completely declarative, while the actual codes are done in GetData method, which is defined at ISDataSource level (and works consistently with datasource control architecture that introduced in ASP.NET 2.0). This allows you to create as many pages as you like, and simply refer to the desired data object without the need for extra coding. It’s that simple.

Next, we will make available an in-depth knowledge base article that explains the technique we used in the sample. It’s unfortunate that we can’t ship the sample in our product installer due to the size of the large database sample (which is around 500MB in size).

I hope this post satisfies your hunger in knowing and learning more about some performance topics in our products. Enjoy, and have a nice day

Best Regards,
Jimmy.