Designing browser-enabled forms for performance in InfoPath Forms Services (Part 3)

Part 3 – Postbacks and the conditions that make them expensive

Welcome to the third article in our series on optimizing the performance of InfoPath browser-enabled forms. In our first article, we defined performance in terms of responsiveness (and identified postbacks as a major cause of poor performance). In our second article we listed a number of conditions that cause postbacks. This article continues our examination of postbacks, looking at conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system.

What is an “expensive” postback?

So what do we mean when we say a postback is “expensive”? Simply that it uses more server resources and takes more time to process the request and generate a response. For an individual form session, the result might be that form updates feel sluggish to the user. For a server processing many requests, the result might be that the performance of all requests is reduced as more resources are consumed.

Most issues that involve expensive postbacks happen when the server must process form data changes, execute data connections, or run business logic that involves form code and event handlers. Postbacks are also more expensive when the amount of data is large, such as when there are attachments or pictures, digital signatures, or when the form is large and contains a lot of XML. Also, complicated XPaths or inefficient schema constructs demand additional processing resources. These conditions are exacerbated when they require SQL Session state management.

The following items are some of the things that can increase the cost of postbacks.

Session state

For InfoPath Form Services, session state is a mechanism for maintaining the state of a form during a user’s form-filling session. For each session, it contains information about both the form data and the state of the form itself. Form Services uses session state to coordinate form changes between the browser and the form server and to improve server performance by reducing the communication required to synchronize them.

This session state data is maintained in a SQL Server database by the Session State service, a shared service used by Form Services to keep track of open sessions for each form user connected to the server. This shared service is implemented by the underlying ASP.NET Session state for the farm rather than InfoPath Form Services, so if other Office products are deployed on the same server, the session service may also be used to maintain the state of user sessions for those applications as well. Depending on the server load, this could lead to contention for server resources between InfoPath Form Services and other products.

Maintaining session state data in a SQL Server database helps improve network bandwidth by reducing the communication between the browser and the Web Front End (WFE) server. However, there is a cumulative performance impact on the WFE and computer running SQL Server as the number and size of the sessions increase. As a user’s session data grows, transferring, loading, and saving the session data takes longer, and more memory is consumed on the WFE. One way session size can grow happens when a user opens multiple forms in the same browser session. In this case, data for each form is combined in a single session, which reduces performance due to the large amount of session data that must be managed. The best way to avoid this condition is to add a button on the form that submits and closes the form (quitting the browser also closes the session, but adding a button allows users to keep their browser open after completing their work in the form). If the computer running SQL Server is separate from the server running Forms Services, which is common, then there is also an impact on the communication channel between the SQL Server and WFE servers. This can quickly become a bottleneck when a large number of multiple concurrent sessions must be managed.

For smaller sessions, InfoPath Form Services can use Form View as an alternate method for managing the state of a session. Form View is implemented by using ASP.NET View State and the session data is kept as part of the HTML page and sent from the browser to the server on every postback rather than being kept in the SQL Server database. The Form View session is maintained on the browser side, and all session data is included in each postback to the server, up to a default maximum size of 40KB. If the View State session data grows above 40KB, it automatically switches to session state and is managed using the session state database on the SQL Server of the farm. Form View uses more network bandwidth than session state, but decreases load of the computer running SQL Server or the communication channel between servers. Consequently, for environments with smaller groups of users, we recommend configuring InfoPath Form Services to use Form view. For environments that must support many users, session state reduces the exchange of View State session data, reducing the size of postbacks, and generally produces the best performance.

There are several specific conditions that increase the size of a session, making postbacks more expensive due to the added session state management load. For each postback request, the form’s state must be restored on the server, then all changes must be processed, saved, and sent back in a response to the browser. The form’s state is stored in either View state or Session state and needs to be restored by server when the next postback request for the form comes from the browser. The larger the amount of data involved, the more it slows down saving and restoring form state on each postback.

  • Data Adapters
    • When a data connection returns data, it is stored in the form’s state, either View state for small sessions or the session state database for larger sessions. The larger the amount of data, the more it slows loading and saving updates to the session state database and the form XML.
  • Attachments or pictures
    • A file attachment control increases the maximum session size by 50 percent. If the maximum size is normally set at 4MB, adding an attachment control to the form template increases it to 6MB. This additional space is allocated to accommodate the base64 encoded binary data of the attachment.

    • Consider the number of attachment controls you add to the form template, especially if the attachments or pictures might be large.

    • If you expect that number of forms sessions with large attachments or pictures will be low, the performance impact will be limited to individual editing sessions. If you expect that many of the sessions will contain large attachments, the performance hit is more likely to reduce the scalability of your form system.

    • If you need to accommodate multiple attachments, or very large attachments, you might want to investigate developing a custom solution so that attachments are not stored in the form, but are stored in a location outside the form, such as a SharePoint document library or a database.

  • Digital Signatures
    • Multiple signatures can inflate the data size of an XML form by 500KB or more for each signature. Each signature is stored as base64 encoded data.

    • Although Internet Explorer uses an ActiveX control to handle signatures and other browsers embed the signature in the form, all signatures increase the size of the session. For all browsers, the added size of forms containing digital signatures makes postbacks more expensive.

Submitting forms to a SharePoint library

Completed forms are commonly submitted to a SharePoint library. However, libraries are limited to 2000 documents per folder, so as this limit is approached, you will see performance problems. If you anticipate reaching that limit, you can design your form system to submit to an alternate destination. The simplest approach is to make sure that each type of form submits to a separate SharePoint library or folder rather a single library or folder containing multiple types of forms; this approach only defers the problem though. Another alternative might be to use a workflow to move submitted files from the library. A more sophisticated approach is to submit to a Web service. This will require custom development for the Web service, but it allows the most flexibility and scalability since the completed forms can be stored in either a SharePoint library or in a database. A solution that submits through a Web service to a database offers the best performance and scalability for large form systems.

First request optimization

InfoPath Form Services uses a technique called first request optimization to improve the loading performance of a form the first time it is requested. First request optimization involves pre-rendering an instance of the form from the form template when the form template is published. This form instance does not require a session state database entry (because there is no user session yet for an initial request). When first requested by a user, the pre-rendered instance of the form is sent to the browser for rendering so the user doesn’t have to wait while the server initializes the session and loads its version of the form.

However, there are form features that will disable first request optimization. Initial requests for forms that cannot use first request optimization are more expensive, reducing responsiveness and slowing the loading of the form. The following conditions are examples of things that prevent this optimization:

  • The use of current time and data functions as default values

  • Secondary data source queries that execute on load (except XML files that are part of the form)

  • Rules or business logic that run on load

  • The use of a username for a default value

  • Any other environment-related or dynamic information that requires server processing

When you publish a new form template, you can determine whether first request optimization is being used by checking for the presence of an ASP.NET session ID cookie immediately after requesting a new form (you can use an HTTP scanner tool such as Fiddler2 to check for the cookie in the response). If there is no cookie, then the form is using first request optimization. Perform an action that triggers a postback, such as switching views, and you will find a session ID cookie.

Business logic changes to XML and cascading events

When a postback involves business logic that makes changes to the form XML on the server, each change to the XML causes events to fire. This can cause an expensive chain of processing operations if the event handling is set up so that an XML change causes a cascade of events that make additional XML changes. Although the number of nested changes is restricted, there is no restriction on how many XML nodes are changed by a single event listener. Consequently, if an event listener changes more than one XML node and each change causes other listeners to fire and make changes to other XML nodes, then the total number of events invoked and XML changes made could be significant. The processing required to execute the cascade of events can use significant server resources, reducing throughput, scalability, and responsiveness. This situation is similar to the event handling issue discussed in the previous article on causes of postbacks, and likewise, it is important for performance and scalability that you understand and carefully scope events to reduce unnecessary server stress.

Custom hosting pages

Another issue discussed in the previous article on causes of postbacks addresses an advanced form scenario that involves using a custom ASP.NET page to host the InfoPath Form control. Since the emphasis here is on conditions that make postbacks more expensive, it is worth noting that although a custom solution offers significant flexibility, you also give up some of the optimizations provided for forms published using the InfoPath Form Designer. One of the optimizations you lose is that postbacks that need to communicate with the hosting page cannot communicate using partial postbacks, and instead must use more expensive full page postbacks. However, if the hosting page just needs to display a form (but doesn’t need to listen for a submit to host event), then there is no change in the form’s postback behavior and partial postbacks can be used. Also, as noted previously, with each postback there is additional processing on the server because the ASP.NET page controls must be rebuilt; and if the page is hosted on a SharePoint site, it also must initialize the complete SharePoint page infrastructure as well.

Additional considerations

As you might expect, this list of conditions that can make postbacks an expensive operation is not comprehensive. In fact, almost any postback can be expensive, depending on type and extent of the changes involved. We’ve highlighted some important issues above and in the previous article on postbacks. If you consider the other issues listed in that article - complex calculations and XPaths, out-of-context and multiple binding - you can see that they also imply performance and scalability impacts arising from expensive processing operations on the form server. If something causes a postback because it requires the processing power of the server, then it necessarily adds to the server load, affecting resource utilization, throughput, and scalability. These issues become more important as the number of concurrent users increases, and as the size and complexity of the forms increases.

What’s next?

The next article in our series on understanding and optimizing the performance of browser-enabled forms will address conditions that affect form rendering in the browser. We’ll also look at an important tool provided by the InfoPath Designer for optimizing browser-enabled forms and controlling postbacks, the Design Checker.