Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

June, 2008

  • Microsoft InfoPath 2010

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


    Part 6 – Addendum: Links to related performance resources

    Welcome to the sixth article in our series about designing InfoPath browser-enabled forms for better performance and scalability. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. We also described some of the issues that affect form-rendering performance in the browser and suggested using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer. Finally, we listed some useful performance monitoring counters available in PerfMon.

    In this addendum, we list a variety of links to additional resources you might want investigate if you are interested learning more about designing forms with InfoPath 2007. In keeping with our theme, the emphasis is on performance, but you will also find other related resources that you can use to broaden your understanding of the online forms environment. Since InfoPath is built on SharePoint technologies, the following resources provide information not only on InfoPath Forms Services and browser-enabled forms, but also SharePoint, ASP.NET, and SQL Server. In addition, we’ve included some general resources on monitoring and testing, and thrown in a few good blogs as well.

    Hope you’ve found this series helpful in demystifying InfoPath browser-enabled forms performance. Be sure to let the InfoPath team know if you have comments or questions about your own forms requirements by adding comments here or on the InfoPath newsgroup listed below!


    Brad Valantine
    Technical Writer


    Improving the Performance of InfoPath 2007 Forms
    A whitepaper about performance and the InfoPath rich client. Because of differences between the client and browser-enabled forms, not everything applies to Forms Services and browser forms, but a must read nonetheless.

    InfoPath Forms Services best practices

    Microsoft Office Forms Server TechNet TechCenter

    InfoPath Forms Services roadmap

    InfoPath 2007 features that are unavailable in InfoPath Forms Services

    Forms Server 2007 Home Page

    InfoPath 2007 Home Page

    Planning and architecture for Office Forms Server 2007

    Plan InfoPath Forms Services

    Office Developer Center: InfoPath 2007 Resource Center

    InfoPath Forms Services Architecture

    Form Development and Deployment Lifecycle

    Creating InfoPath Form Templates That Work With Forms Services

    Support: Microsoft Help and Support: Forms Server 2007 Solution Center


    Plan for performance and capacity (Office SharePoint Server)

    Plan for performance and capacity (Windows SharePoint Services)

    White paper: Intel Performance Testing of Windows SharePoint Services (WP)

    How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance

    White paper: Planning and Monitoring SQL Server Storage for Windows SharePoint Services: Performance Recommendations and Best Practices


    ASP.NET Performance

    ASP.NET Session State Overview

    Developing High-Performance ASP.NET Applications

    Monitoring ASP.NET Application Performance

    SQL Server

    Performance (Database Engine)

    Monitoring (Database Engine)

    Monitoring and Testing

    Life-Cycle Performance Testing for Eliminating Last-Minute Surprises

    Server Performance and Scalability Killers

    Performance Counters in the .NET Framework


    Designing Forms for Microsoft Office InfoPath and Forms Services 2007 (Microsoft .NET Development Series)
    By Scott Roberts and Hagen Green
    Publisher: Addison-Wesley (c. 2007)
    ISBN 0321410599

    A couple of great online books from the folks in Patterns and Practices:
    Improving .NET Application Performance and Scalability

    Performance Testing Guidance for Web Applications


    Blogs and Newsgroups

    Pashman's InfoPath Goldmine: Tips and Tricks for Tuning Forms Services Performance

    Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests
    The first article in a series about research done by Yahoo into web page performance optimization.

    Agile Testing: Performance vs. load vs. stress testing

    Ben Curry: Using Performance Monitor (perfmon.exe) to Monitor SharePoint Server 2007

    Ben Curry: SharePoint Server 2007 Performance Counters

    Thom Robbins .NET Weblog: InfoPath Tips and Tricks

    Joel Oleson's Blog - SharePoint Land:
    Performance & Scale

    Good List of Performance Counters

    S.Y.M. Wong-A-Ton: Enterprise Solutions

    Paul Vick - Panopticon Central: The Ten Rules of Performance

    Technorati - infopath Blogs, Photos, Videos and more on Technorati

    Discussions in Infopath General Questions
    Use this newsgroup to communicate with the InfoPath community.

    MSDN Forums: SharePoint - InfoPath Forms Services
    This forum is another place you can ask questions about Forms Services.


  • Microsoft InfoPath 2010

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


    Part 5 – Addendum: Counters for monitoring form server performance

    Welcome to the fifth article in our series on optimizing the performance of InfoPath browser-enabled forms. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. We also described some of the issues that affect form-rendering performance in the browser and suggested using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer.

    In this addendum article, we list some useful performance counters you can use in the Windows Performance Monitor (PerfMon) to monitor the behavior of your form server system. Using a combination of general system counters and InfoPath-specific counters to monitor the performance of your servers can help you troubleshoot issues and quantify the performance effects of changes you make to the design of your InfoPath form templates.

    System counters for monitoring your form server system

    There are two key places where performance bottlenecks can occur in your form server system, on your Web front end (WFE) servers and on your SQL Server back end. The bottlenecks that occur on the front end are normally CPU bound, while the bottlenecks at the SQL Server back end are normally either disk bound or CPU bound.

    You can use the following system counters in PerfMon to check the performance of your WFE and SQL Server systems under various load conditions. Use these counters to determine whether your servers are performing at acceptable levels and to help identify any bottlenecks.

    Counters for monitoring a WFE server system

    • CPU:
      Processor\% Processor Time\_Total
      Indicates the total CPU load on the server.

    • ASP.NET:
      ASP.NET \Requests Queued
      A linear increase of this counter with user load can indicate that an application is experiencing a bottleneck, either at the front end or the back end. Correlate with other ASP.NET counters, SQL counters, and WFE CPU counter to understand which part of the system is getting bottlenecked.

      ASP.NET\Requests Execution Time
      Use this counter to find which type of form template takes more time to execute in the server. In general, forms with managed code require more execution time than forms that don’t. If this counter and WFE CPU counter are high while the SQL transactions/second counter and SQL CPU counter are low, then the bottleneck is at the WFE side. This may be an indication that the form complexity is high or that the form has a lot of managed code.

    • Memory:
      No. of current logical threads
      If the count is increasing, then the thread stacks are leaking.

      Private bytes and No. of bytes in all heaps
      If the count of private bytes is increasing while the number of bytes in all heap counter is stable, then the unmanaged memory is leaking.
      If the count of private bytes is increasing and the number of bytes in all heap counter is also increasing, then the managed heap is building up.

    Counters for monitoring a SQL Server system

    • CPU:
      Processor\% Processor Time\_Total
      Values above 25% indicate a possible bottleneck. Values above 80% signify extreme CPU-bound SQL operations. A linear increase in CPU with user load indicates that SQL will become a bottleneck.

    • Disk:
      Counter should be less than 1.5 or 2 times the number of RAID disks. Correlate with % Disk time counter and Current Disk Queue counter to determine whether the disk is a bottleneck. Decrease your test load to see if the values go down.

      SQLServer:Locks\Number of Deadlocks/sec\_Total
      Value should be zero.

    • Memory:
      Non-zero value for a sustained period of time indicates that the system is experiencing a high memory load. SQL Server works best when the operating system does not reallocate its memory.

    Counters provided by the InfoPath Forms Services performance object

    InfoPath Forms Services installs a set of counters that can be viewed in PerfMon. There four types of counters provided by the InfoPath Forms Services performance object: Transaction, Session, Data Connection, and Template/Document.

    • Transaction counters represent all communication between the browser and the server. You can use the transaction counters to monitor how long postbacks are taking to complete and as a gauge for how expensive they are for the server to process.

      Avg. Transaction Duration
      The average time to complete a transaction in form-filling sessions.

      Transactions Started Rate
      The rate at which transactions started in form-filling sessions.

      Transactions Completed Rate
      The rate at which transactions completed in form-filling sessions.

    • Session counters provide duration and rate information for user form-filling sessions. If there are too many active sessions for the server to handle, you will see excessive average durations that indicate a server bottleneck.

      Avg. Session Duration
      The average time to complete a form-filling session, summed up over all transactions in the form-filling session.

      Sessions Started Rate
      The rate at which form-filling sessions started.

      Sessions Completed Rate
      The rate at which form-filling sessions completed.

    • Data Connection counters show the duration and rate of both data connection submit and query activities, along with failures. This will give you an indication of back end performance and how long data connections are taking to complete.

      Avg. Data Connection Submit Duration
      The average time to complete a data connection submit in form-filling sessions.

      Data Connection Submit Started Rate
      The rate at which data connection submits started in form-filling sessions.

      Data Connection Submit Completed Rate
      The rate at which data connection submits completed in form-filling sessions.

      Data Connection Submit Failure Rate
      The rate of failures for data connection submits in form-filling sessions.

      Avg. Data Connection Query Duration
      The average time to complete a data connection query in form-filling sessions.

      Data Connection Query Started Rate
      The rate at which data connection queries started in form-filling sessions.

      Data Connection Query Completed Rate
      The rate at which data connection queries completed in form-filling sessions.

      Data Connection Query Failure Rate
      The rate of failures for data connection queries in form-filling sessions.

    • Template/Document counters give information about the number of forms and form templates that are currently in the ASP.Net cache and in memory. These can help you monitor and detect memory utilization issues on your server.

      # of Cached Form Templates
      The number of form templates that have been added to, and not yet expired out of, the ASP.NET object cache.

      # of Business Logic Assemblies in Memory
      The number of business logic assemblies currently loaded in memory. Administrator-approved form templates may contain zero, one, or more managed code assemblies.

      # of Form Templates in Memory
      The number of form template objects that are currently loaded in memory.

      # of Cached Form Templates in Memory
      The number of forms that are currently loaded in memory.

    Server system health monitoring

    The general system counters and InfoPath Forms Services counters listed above are useful for monitoring specific issues on a server, but do not provide comprehensive health monitoring for your overall form server system. For that you need to use a solution designed to watch multiple servers for issues that may cause service or performance degradation, such as Microsoft System Center Operations Manager 2007. Operations Manager uses management packs that contain predefined rules, settings, and agents to monitor a specific service or application. For SharePoint, you can download the SharePoint Monitoring Toolkit, which contains the management packs and documentation for both Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. Note that System Center Operations Manager also provides the capability to customize existing rules or create your own rules.

    For more information about the SharePoint management packs for Operations Manager 2007, see the SharePoint Monitoring Toolkit Executive Overview (

    For more information about Microsoft System Center Operations Manager 2007, see the System Center Operations Manager TechCenter (


  • Microsoft InfoPath 2010

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


    Part 4 – Browser Rendering Issues

    Welcome to the fourth article in our series on optimizing the performance of InfoPath browser-enabled forms. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. In this article we’ll examine some of the issues that affect form rendering performance in the browser. We’ll also take a quick look at using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer.

    Conditions that slow form rendering in the browser

    There a several conditions that can reduce form-rendering performance in the browser. The main effect of these conditions is that the user experiences delays and sluggishness when working with the form. The reduced performance experienced because of slow form rendering in the browser generally occurs at the following times:

    • When the form initially loads

    • When the form is updated and re-rendered after a postback response

    • When there is a change to the display of the form in the browser that does not involve a postback

    If the designer can reduce or eliminate conditions that are more expensive for the browser to render, the form will render more quickly, and feel more responsive to the user. As with other design issues we’ve examined that affect postbacks and server performance and scalability, addressing performance issues that affect browser rendering must be balanced with your unique design and business requirements.

    • Rich Text Box control

      The Rich Text Box control creates HTML elements for the content added to a rich text field. Depending on the amount of content and formatting added by the user it can end up creating a large number of HTML elements, which can impact browser performance. One issue with using a rich text field is that you cannot predict how much data a form user might add to the field. For example, a user could paste a large rich text selection into your form from just about any source. Although the Rich Text Box control for a browser-enabled form does not allow embedded images, only linked images, the content could still be quite large.

      Unfortunately, for browser-enabled forms the InfoPath Designer does not provide a way to limit the amount of data entered. Consequently, you should consider carefully how your users are likely to use any rich text fields you add to the form and limit the number of rich text fields that are visible in a view. If you need multiple rich text fields, consider using multiple views rather than putting them all on a single view. As an alternative, consider using a Multi-line Text Box control instead.

    • Nested Tables

      Rendering HTML code for tables is a relatively expensive operation for a browser. Nesting tables by inserting one table inside another, especially if they are nested several levels deep, compounds the complexity and is generally slow for a browser to render. For better rendering performance, consider using adjacent non-nested tables rather than nested tables.

    • Conditional formatting

      We looked at conditional formatting in an earlier article, touching on the interaction with postbacks to the server and how conditional formatting expressions fire each time the form is re-rendered. Since the browser must manipulate all the data, whether it is visible or not, this can be an expensive operation that makes the form display feel less responsive. While conditional formatting can be a useful design tool, there are times when the performance cost may outweigh the benefits. For example, if a form contains a large amount of data and a substantial part is hidden, the conditional formatting can slow the form display even though some of it isn’t rendered.

      In this case, designing the form with multiple views might improve the form’s display performance compared to the single view with hidden content. Although it will cause a postback each time there is a switch to another view, the user’s interaction with each of those views in the browser may feel more responsive. This is because each view has a smaller amount of data to render than the single view containing hidden data. The tradeoff you need to consider here is between the browser-side responsiveness of the form display and the server-side scalability of your form system as it processes postbacks: using conditional visibility might slow form display, but reduce the number of server requests, while using multiple views improves form display, but increases server requests and reduces scalability.

      As another example of how subtle performance tradeoffs can be, as noted in the earlier article, it is also possible to have a design where the form display is more responsive if it uses conditional formatting to hide some data. This is happens in a situation where the browser actually takes longer to render all the elements than it takes to process the conditional formatting and hide some.

      If you suspect you have a situation where conditional formatting could either help or hinder your form’s performance in the browser – or your server scalability – try alternate designs and test them to determine which design best meets your requirements.

    • Drop-Down List Box controls with many items

      Drop-Down List Box controls can generate a large amount of HTML, especially when there many items provided in the list. The amount of HTML balloons when the list control is contained in a repeating section or table. For example, if you include 50 items in a list, and the list is repeated 50 times, the underlying HTML code will grow very rapidly and slow down rendering of the form! Try to limit the number items in lists that are used in repeating elements or limit the number of repeating elements. Alternatively, you can try using conditional formatting, putting the repeating elements containing drop-down lists into a section that is hidden by default. Because they are not supported in browser-enabled forms, some of workarounds you might consider using if you are familiar with InfoPath rich-client forms, such as a Master-Detail control or one of the other list controls, are not available. About the only other alternative might be to emulate the list using a repeating table with each item on a row (and some fancy formatting). One situation to watch out for is using an external data source to provide the list items. If you need to do this, then you also need to make sure the number of items provided by the data source is limited to a reasonable number. As with any design, it is always a recommended best practice to test alternative designs for expected (and exceptional) data sizes to determine how your form designs perform.

    • Many visible controls

      Forms that have a large number of InfoPath controls visible in a view will reduce browser performance. Again, this is amplified when the controls are in repeating sections or tables. The first suggestion is to use multiple views so that each view has fewer controls to be rendered. If you use multiple views, make sure that controls are only bound once in the view in which they are used (use the Design Checker). Once again, you can also use conditional formatting to hide some of the controls, but this will typically achieve a smaller gain in browser performance compared to using multiple views. Because there are a number of important variables that determine browser rendering performance, your design alternatives should be tested in the common user environments you expect (data size, browser type, user's machine configuration) to determine acceptable number of controls and the relative performance of each design.

    • Calculations that use large data sets

      If you design a form that includes calculations and the data for the calculations is loaded from an external data source, then that data will be downloaded to the browser so that the calculation can run in the browser without a postback to the server. Normally this strategy improves overall performance by reducing postbacks. However, if the data set is large, the benefit of eliminating postbacks can be overtaken by the performance cost of handling the data in the browser. First, it is more expensive to load a large data set; second, it is expensive to run after it is loaded.

      If you find that the browser is too slow when running calculations with large data sets, you can force a postback so that the calculation runs on the server instead. In the InfoPath Designer, for the field that runs the calculation, add a button and change the postback setting to always require a postback. When the user clicks the button to run the calculation, it will postback to the server to evaluate the calculation and return the result to the browser for display. Like most performance suggestions, you need to balance performance in the browser with the performance and scalability of your form server system.

    • Reporting scenarios

      InfoPath is primarily designed to address form-filling scenarios. Although it can also be used to display data in a reporting scenario, this can have a negative impact on browser performance as the amount of data downloaded for display increases. If there is a possibility that the amount of data could be very large, then you can expect performance problems not only in the browser, but also on the server. Depending your ability to predict and limit the amount of data in a reporting form, it might be possible to maintain acceptable performance by using multiple views and read-only controls. However, if the data is too large or cannot be limited practically, you should consider an alternate reporting solution.

    • Internet Explorer 6

      If you have form users that are using Internet Explorer 6, they will experience reduced browser performance compared with other browsers due to known issues with IE6 JavaScript performance. You might consider providing a statement on your site about browser support, and if you know you have a substantial number of users running IE6, then it is a good practice to include IE6 performance testing in your development plans.

    Use the Design Checker to monitor browser compatibility issues

    The InfoPath Designer allows you to design forms that run in both the rich-client and a browser. When you are designing browser-enabled forms, and especially when you want your form to support running in both environments, you need to be careful about browser compatibility issues. As you are designing a form template in the InfoPath Designer, you can use the Design Checker task pane to monitor any browser compatibility issues detected by InfoPath, including those that affect performance.

    Among the messages displayed by the Design Checker are warnings for controls that will trigger postbacks to the server (these messages are hidden by default; to view them, select "Browser Optimization Messages" from the Options button at the bottom of the Design Checker). One or messages can appear for each control that will post back to the server when the value of the control changes.

    Sometimes the postback occurs because of a calculation, binding, or other expression on that control. Occasionally a control will post back to the server not because of a property on that control, but because that control is contained inside a section or a table where some other control forces a postback, or the control contains a section, table, or other controls inside it that cause a postback. In these cases, the warning messages indicate that you should look for another control marked as a primary cause of the postback; examining the messages for that control can help you locate, understand, and control postbacks caused by related controls.

    If having other controls bound to the same element or group are causing unwanted postbacks, consider using separate views, with the control bound once in each view.

    To resolve issues where the binding of the control requires server evaluation, or a node is listed as only available on the server, you might need to simplify your schema.

    You can change the default postback behavior for an individual control using the Postback settings options on the Browser forms tab in the Properties window for the control. There are three options available: Never, Always, and Only when necessary for correct rendering of the form (recommended). You can reduce the number of postbacks by changing the setting to Never. If you select Never, then the control will not send data to the server on change; the data will only go to the server and formatting, calculations, etc. will only run when the form user saves or submits the form, or another control in the form causes a postback to the server. For controls you want to change, you must change the postback setting option on each control individually; changing the option on a section or group control does not automatically change the value for every control inside it.

    Note that you should carefully consider the effect of changing postback behavior to ensure that the result is acceptable for your environment. Be careful about suppressing postbacks that affect the user’s form-filling experience to avoid issues where displayed data could be incorrect. You never want to sacrifice data integrity for a potential gain in performance. If you make any change to the postback settings, it should be thoroughly tested to ensure the form behaves correctly.

    What’s next?

    The next article in our series provides information on some of the useful performance monitoring counters that can help you evaluate the performance of your form system.

  • Microsoft InfoPath 2010

    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.


  • Microsoft InfoPath 2010

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


    Part 2 – Postbacks and conditions that cause them

    Welcome to the second article in our series on optimizing the performance of browser-enabled forms designed with Microsoft Office InfoPath 2007. In our first article, we defined performance in terms of responsiveness. In this article, we’ll focus on postbacks, one of the most common causes of reduced performance

    Postbacks are probably the most important factor affecting form performance because the effect of other conditions is amplified with each postback. There are two significant aspects of postbacks which we’ll examine in this series. First, which form features cause postbacks? Those features are the subject of this article. Second, what kinds of postbacks are more expensive to process, thus imposing an additional burden on the performance and scalability of the form system? We’ll examine those factors in the next article.

    What is a postback?

    Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and usually occurs when a form feature needs to send data to the server for processing. After sending the postback request, the browser must then wait for a response before it can update and re-render the form with the new data. In the case of a full-page postback, the browser must stop rendering completely until the whole updated page is returned, blocking user interaction with the form until it has been re-rendered. Alternately, to improve the user experience in the browser, some features use a partial postback, where only a specific part of the form is updated. This allows the user to continue interacting with other parts of the form while the update happens in the background. In either case, however, unnecessary postbacks impose an additional load on both the browser and the server. If you can reduce or eliminate postbacks as you design, develop, and test your forms, you can improve the performance and scalability of your entire form system.

    Browser-enabled form handling compared with InfoPath client forms

    To better understand the effects of postbacks on performance, it is helpful to compare basic form handling of the InfoPath-rich client with InfoPath Forms Services and browser-enabled forms. Whether you are new to InfoPath, or you are familiar with rich client forms but new to InfoPath Forms Services and browser-enabled forms, understanding these basic differences will help you improve your form design and troubleshooting strategies.

    The major difference between the InfoPath-rich client and browser-enabled form systems is that the InfoPath client doesn’t need to communicate with the form server as frequently as the browser does. This is because the InfoPath client processes most forms locally on the user’s computer. In contrast, the browser form relies on the server for a variety of form processing operations, requiring more communication to exchange data between the browser and the form server. Communication in the form of postbacks is a fundamental feature that allows InfoPath to support browser-enabled forms on the Web, but postbacks also make browser forms more sensitive to performance issues.

    Let’s look at two form loading and editing scenarios that further illustrate the difference between form processing in the InfoPath client and browser-enabled form systems.

    In the InfoPath-rich client scenario, when the user opens the form from a SharePoint form library, InfoPath first determines that the form should be opened in the client rather than the browser. After the initial download of a copy of the requested form template, InfoPath opens and renders an instance of the form on the user’s computer for editing. The form instance in the client is an XML document that the client renders in HTML for display. As the user interacts with the form, the InfoPath client processes and renders changes, and might run some custom form code, all within the context of the client running on the user’s computer. Generally, the only time the client needs to connect back to the server is to make additional data connection requests to query from or submit to a data source, to save a partially completed form, or to submit the final form.

    In the case of the browser-enabled form, when InfoPath Forms Services receives an initial request for the form from the browser, the server starts a session for that user’s form-filling session, allocates server resources, and processes the browser-enabled form template to load an instance of the form XML for the session. In addition, if the form requires it, the server might load and run custom form code and load data from a data source. After this initial processing, the server assembles the JavaScript and HTML that represent the form instance to be downloaded to and rendered by the browser.

    Finally, the server sends the response through a Web Front End server over the network to the browser on the user’s computer, which renders the initial download into the form view that the user interacts with. As the user interacts with the form in the browser, some form processing happens in the browser, but more complex form elements and events require a postback to the server for processing.

    During the transmission and processing of the form data, the browser instance of the form must wait for a response and then re-render the updated form. In this communication cycle, each postback request and response set constitutes a roundtrip. Each roundtrip affects the performance and scalability of the form system in terms of throughput, responsiveness, and resource utilization. This impacts both the browser side and the server side, as well as the network.

    As you can see from these two scenarios, a form-filling session in the browser-enabled form system requires substantially more communication than a similar session in the InfoPath client. In addition, more of the browser-enabled form processing is concentrated on the server, especially when multiple form-filling sessions are being served. In contrast, with an InfoPath client form, the form processing is distributed to the user systems. Consequently, reducing the number and complexity of postbacks as you’re designing browser-enabled forms can substantially boost performance.

    Ten common causes of postbacks

    1. Complex calculations

      A calculation can cause a postback when there is a condition that cannot be evaluated in the browser and requires processing by the server. For example, if a calculation requires data that is not loaded in the DOM, then the browser must send a postback to the server and wait for the result. Another condition that will invoke a postback involves any calculation that is out of the context of the current node. For example, you could create an expression such as .\.\.\my:field1+. When the expression is invoked in the form, because it requires traversing up the tree several levels from the current node, it must be sent to the server for evaluation.

    2. Data adapters

      The function of a data adapter is to make a query connection to an external data source, such as an XML file, a database, a SharePoint list, or a Web service, so that a form can receive and be updated with some data from the data source. If a form invokes a data adapter when the form loads, the browser must wait for the data connection, increasing form load time. If the form invokes a data adapter after the form loads, a postback containing the query request is first sent to the form server, which executes the data connection request on behalf of the browser form, adding additional time to the roundtrip.

    3. Multiple binding: data bound to multiple controls

      Multiple binding happens when one piece of data in the form is bound to two or more controls in the same view. This is usually done so that the same data can be displayed in multiple places. For example, you might design a report with several sections to include a single non-repeating field, such as "Report Date", inside a repeating section so that the same date is displayed in each report section. If you design a form this way, then changing the "Report Date" field in one location will update it everywhere because it is multiply bound. Unfortunately, the cost of this multiple binding might be a roundtrip to the server if the binding is more complex than the browser can resolve. In this case, server analysis is required to reliably identify all the controls bound to the same piece of data. In addition, if something is both multiply bound and out of context, then user edits to form fields will always require roundtrips. Other form actions that will cause roundtrips to the server when there is multiple binding include insertion or removal of repeating tables and repeating or optional sections.

    4. Out-of-context binding

      Out-of-context binding describes a situation where a control inside a repeating or optional section is bound to a node that is in a different part of the XML data source tree, outside the group node that contains the repeating or optional section control. When an out-of-context situation occurs in a form, the correct binding may be too complex to determine within the browser. If either the validity or the kind of action—such as a calculation—cannot be determined in the browser, the out-of context binding will trigger a roundtrip to the server to resolve the binding.

      You are most likely to encounter this problem as you’re designing a form in the InfoPath Designer if you first insert a group or control, and then later decide to move that group or control into an optional section. To avoid creating an out-of-context binding, after you drag and drop the control into the optional section, in the data source pane, drag the node the control is bound to into the group for the new optional section. The group or control will then be bound to the correct context.

    5. View switching

      Multiple views are often used to present a specific view to a specific user audience in a workflow. Multiple views are also commonly used to improve the performance of a form; by careful grouping of related items and limiting the number of controls in each view you can improve the form loading and rendering performance compared to placing everything in a single view. However, each time the view is switched, there is a full postback to send the user’s changes to the server, get the new view, and reload it in the browser. If possible, try to group the items on a view so that any controls that might postback do so when the view is switched. Then only one postback occurs when switching the view. A good example of this is using a button to invoke a query connection that returns data for a list, an operation that requires a postback. If the view is also switched when the button is clicked, you improve the efficiency of the postback. Another benefit of this design is that it makes the view switch a user-invoked action, which improves the user’s perception of the form response. By coordinating the postback of controls in the view with a view switch, you not only improve the responsiveness of the form, but also reduce stress on the server and network by eliminating extra postbacks. When designing your form there is no formula for when to use multiple views, so you will need to balance your use of multiple views with the potential design and performance advantages and costs in your user scenarios.

    6. Conditional formatting

      Conditional formatting is commonly used to hide part of a form from view until some condition is met. However, conditional formatting expressions fire every time the form is rendered whether hidden or not. Additionally, all of the data, calculations, and expressions used by fields that are conditionally hidden are still downloaded and can cause extra performance overhead. Thus if anything else invokes a postback, your form will incur this additional overhead. Similarly, if the conditional formatting requires a postback, then there is a postback each time the form is rendered. Although the primary reason for using conditional formatting has more to do with your form design and presentation, there may also be a slight increase in the responsiveness of the form if it uses conditional formatting. This is possible because it can be slower to render something in the browser than to execute the conditional formatting. However, if you need to substantially limit the presentation, consider using multiple views instead of conditional formatting because multiple views generally perform better.

    7. Digital signatures

      For forms that are filled out in Internet Explorer, signing a form uses an ActiveX control that communicates with the server using out-of-band postbacks. The signature operation involves 3 main steps:

      1. Gather client-specific information to be used by the signature data
      2. Server preprocessing to prepare the stored XML document for signing
      3. Apply the final signature

      Each step causes a postback, the first and the last being relatively expensive. This is because the first postback sends, among other things, the data corresponding to the non-repudiation image to be stored in the signature. The last is a full postback that refreshes the browser with the new signed document that has been prepared on the server.

    8. Business logic event handling

      Normally, when a user changes the values of several controls in the browser form, the JavaScript form logic in the browser can optimize the changes, batching them together to avoid a postback for each change. This reduces the number of postbacks to one. However, this optimization is not possible if the form has code or other logic, such as rules or conditional formatting, that listens to data changes in parts of the XML DOM. For example, if a control is bound to a particular DOM element and a listener is present, changes in that control are immediately communicated to the server and the corresponding event handler invoked. The number of extra postbacks depends not only on the number of event handlers, but also on the XPath they use to listen to DOM events. This is because InfoPath XML events bubble. For example, if some form code has business logic with an event handler that listens to a node close to the root node, there will be relatively more postbacks. This is because any browser change affecting one of the descendants of that node will trigger a postback to the server. Consequently, if your form uses form code or any other construct that involves listening to changes, it is important for performance and scalability that you understand and carefully scope events to reduce unnecessary postbacks and server stress.

    9. Custom hosting pages and external page events

      If you are using advanced form techniques such as developing your own ASP.NET page to host the InfoPath Form control, then there are a couple of things you should be aware of. Submitting to a custom hosting page requires full page postback because the XmlFormView control resides on the server and it involves rebuilding the page controls by ASP.NET. In addition, when submitting the form, before the submit is finalized, data is sent back to the browser with a pending submit action added. This pending submit action must then be sent back to the server in another postback to actually complete the submission. If the page is hosted on a SharePoint site, it also must initialize the SharePoint page infrastructure as well. Also, if an XmlFormView control is hosted on a custom ASPX page and the page listens to events from the control, then every operation triggering an event in the XmlFormView control will require full page postback.

    10. Complex XPaths

      In some advanced form design scenarios, you might build your own complex custom expressions or calculations using the "Edit XPath (advanced)" option. Although most common expressions or calculations can run in the browser, those that require more complex XPaths to evaluate may need to postback to the server. The following complex XPath conditions will cause extra postbacks:

      • More than one possible context for a filter
      • Complex XPath that is not used as a filter
      • XPath where the user input  is not a filter
      • XPath filter or rule that references an element that is not in the current view
      • XPath filter that is position-based
      • XPath with inline functions
      • XPath that includes an unrecognized function
      • XPath that includes an extension function that is not supported by the browser
      • XPath has an inner expression
      • Expressions containing inner nodes


    What’s next?

    In our next article we’ll examine some of the conditions that make postbacks more expensive and that affect the performance and scalability of a server system running InfoPath Forms Services.



Page 1 of 1 (5 items)