Introduction

This article provides guidance and suggestions for improving performance of K2 SmartForms. You can use the tips in this article before you install K2 smartforms, when you are designing or building your Views and Forms, and to troubleshoot performance issues at runtime.

You may also want to refer to the other articles in this series of performance considerations:

Implementation Tips

Here are some tips and guidelines to help you improve performance of SmartForms.

The performance tweaks or configurations settings described in this article may not be available in or applicable to all versions of SmartForms.

Installation and configuration

Tweak, Enhancement or practiceBackground and NotesLearn More
Upgrade to the latest product versions, and install updates. New product versions and updates released for products usually include performance improvements. By upgrading you can potentially improve performance and take advantage of new design-time features and runtime optomizations that may improve the performance of your forms and views. See the release documentation for the product version for general information about changes and enhancements. Product Release history and release notes
Install the SmartForms websites and the K2 host service on the same physical server, and edit the HOSTS file. Installing the SmartForms websites (Designer and SmartForms Runtime) and the K2 host service on the same physical server can help to improve performance.To further improve performance, edit the hosts file on the physical server to add a loopback entry within the HOSTS file on each of the nodes in a K2 farm that maps the DNS name of the farm/load balancer to the local server. Specifically, this means editing the machine's HOSTS file so that when the sites need to connect to the host service, the hosts file will direct the request to the same physical server instead of calling back to the network and potentially connecting to another physical server in the same farm.

Improving Performance

Modifying the hosts file to improve performance for certain environments

Adjust configuration settings for best performance You can edit certain configuration settings in the smartforms web site's web.config file to tune overall performance. K2 Runtime web.config File Performance Settings
Enable IIS caching on the initial load of a form improve performance when you have large complex forms with multiple views, states, events and actions by caching the form on initial load. How to Improve Performance by Enabling IIS Caching on Initial Load of a Form

 

SmartForms Design and Implementation

This section describes some tips and techniques to apply when designing and building SmartForms, to help improve performance.

Tweak, Enhancement or practiceBackground and NotesLearn More
Use Server-Side rules to prepare forms and views before they are sent to the client browser. You can use server-side rule actions to prepare a view or form before it is sent to the client browser, for example to pre-load a view with data, or to show and hide controls before the form is displayed on the browser. This helps to reduce the time it takes to load and display a SmartForm since some of the work is already done before the Form is shown to the user. Server Rules
Execute actions asynchronously (batch or concurrent) where possible Executing actions in batch or concurrently can significantly speed runtime performance, especially in forms with multiple views. You can combine different execution types in a single rule as well.
one after another ("then"): sequential
Separate calls and connections to K2 Server for each action, and each action "waits" for the previous action to finish before it starts. This approach is usually the slowest, but users can work on one item while the other is busy loading.
concurrently ("and"): in parallel
Separate calls and connections to K2 server for each action, and actions return independently of each other. This approach often results in the fastest user experience, but at the cost of network data transfer. You also cannot pass values between views or methods with this approach, since you cannot predict which method will return first.
in a batch ("also"): single job
Single call and single connection to the K2 server with a batch of tasks. The batch is finished on the K2 server before the results are returned to the form/view. This approach results in less data transfer over the network, but the UI can appear locked" while the batch action is performed. This option is the most efficient for reducing network communication, and you can still pass values between SmartObject methods in the rule.
Video: Execution Types in SmartForm Rules
Video: Combining different Execution types in a Rule
How to change when Actions execute in a Rule
Use hidden controls to launch subforms/views that are used more than once in a form When reusing the same view or subform multiple times in a parent form, the parent form copies the rules of that subform/view for every rule where you call the view or subform. To avoid this overhead and bloat, use a hidden button action to launch the view/form with different inputs so that the subform is only imported once. This also helps to simplify maintenance of the parent form. Video: Using hidden controls to open SubForms
Enable paging for read-only list views When using read-only List views for larger datasets (>50 records), enable paging for the list view to limit the number of records returned on the view load. You can adjust the number of records per page in the view rules. Since paging is performed on the K2 server, this can save the amount of data transferred to the client at runtime. Video: Using paging on read-only list views
Filter data as close to the source of the data as possible Where appropriate, use server-side filtering to limit the data returned to the SmartForm. You can define the filter in the view, or if you have static filtering requirement, implement a method with a static-value parameter in the SmartObject definition.
Some service brokers (for example the SQL service broker's "use native execution" option) that offer additional performance improvements.
Video: Using native SQL execution to improve performance of SQL-backed SmartObjects
Execute SmartObject method can be faster than Execute a View method When a form needs to retrieve a value from a SmartObject in a view, and the view does not contain the value yet, it can be faster to call the SmartObject method directly from the form rather than calling a form event to retrieve the SmartObject property. In these cases, use the Execute a SmartObject method action rather than the Execute a View method action Video: SmartObject Methods vs. View Methods
Limit the number of properties returned by a SmartObject used in a drop down list When you use a SmartObject to populate a drop-down list, all the properties of the SmartObject list method are passed to the view, even if you only need one or two properties of that SmartObject in the drop-down list. You can improve performance by creating a new method for the same SmartObject which only returns the properties you need in the drop-down list. Video: Improving performance by limiting SmartObject data
Keep the number of form States for a form to a minimum Whenever you define a new form state, all the rules for the forms are duplicated for the new state. Try to limit form states to only those states that are necessary, or re-use states where possible. When the form states differ significantly, it may be easier to define a separate form than try to handle all possible scenarios in one form definition
Use lookup/picker controls instead of drop-down lists for large data sets If you are populating a drop-down list with a large dataset (50 records or more), it is better to use the Lookup control rather than a drop-down list. If you MUST use a drop-down list, try to populate the drop-down list asynchronously. Where possible.
Refactor, clean and simplify form and view rules Cleaning up form rules and view rules can speed up development and runtime experience. Remove unused rules and try to simplify the actions and conditions as much as possible. Before publishing your form/view, refactor and remove any unused rules and actions from the form/view. This is especially true for rules used only during development or debugging, since they add unnecessary bloat to a form.
Limit rules and actions to only what’s necessary Avoid performing unnecessary rules/actions on a form or view. For example, it is not always necessary to re-initialize a view. Clearing a view's controls can clean the view for input without needing to re-populate the drop-down items on the view, for example. Another example: when you add a view to a form, the form initialize rule is automatically updated to include an action which executes the view’s Initialize rule, even if the view doesn’t have an Initialize rule defined. Make sure that Initialize rules are executed only for the views that have Initialize rules defined.
Remove hidden fields that were only used for development/debugging purposes Hidden fields that are not used just add overhead to a view/form. Remove any hidden fields that were only used for development or troubleshooting purposes. Exception: hidden fields can help to simplify form/view design, so sometimes you will use hidden fields to improve or simplify runtime execution.
Define separate views for List views in read-only and edit mode If you need to re-use the same List view in both Read-Only and Edit modes on different forms, it may be worthwhile to define separate List "Edit-mode" and List "Read-Only" mode views for the List view. Adding complicated rules to enable/disable editing conditionally on a list view with many expressions/rules and validations can impact runtime performance and complicate development.
Load data only when necessary Wherever possible, try to load data only when it is required. For example, do not unnecessarily populate drop-down lists on hidden tabs, or do not unnecessarily populate a list view on initialize if the List view will be populated by a subsequent action anyway. When using tabs, populate the first tab in one execution block and then populate the remaining tabs in separate execution blocks. Where possible, delay the population of the other tabs/views until they are actually needed. You can use certain events or rules to delay populating a form/view with data until the user explicitly asks for that data, and remember to use the various execution Types (e.g. sequential, concurrent or batch) to populate data in the most efficient way. Video: Using Tab events to load data on-demand
Video: Using View events to load data on-demand
Combine Data Transfer actions where possible Populating controls with values using the Data Transfer action is currently a client-side operation. Try to limit the number of individual Transfer data actions and wherever possible. Combine data transfer so that multiple controls/fields are populated in the same Transfer Data action.
Use associations sparingly Discovering associations between SmartObjects can add overhead. For example, while a view can discover an association for the current SmartObject and automatically generate a drop-down list for you, it may be more efficient at runtime if you remove the association and create the drop-down list manually, pointing it to the relevant SmartObject. This way, you remove the additional overhead added by the association.
Use the Execute another rule action to call the same rule definition from different events. If you have rules that are used multiple times from different events, or a sequence of actions that you would like to define as a re-usable 'chunk' of actions, you can define 'event-less' rules with the actions to execute, and then call the event-less rule from another event with the Execute another rule action.
This approach allows you to define a re-usable set of actions once, and re-use the same sequence of actions in different places. It can also reduce the size of the form definition sent to the client and improve runtime performance.
For complex IF…ELSE conditions in a rule, base the rule execution on the value of a hidden control If you have complex IF..ELSE evaluations in a rule, it can be easier to base the IF..ELSE condition on a single hidden control's value, rather than handling all the conditions inside a rule definition. Use "Data Transfer" actions in the IF parts to set the value of the hidden control. Video: Advanced conditional statements in SmartForm Rules

 

Debugging and Troubleshooting

This section lists some logging and debugging tools and resources you can use to debug and torubleshoot performance issues in SmartForms.
Tweak, Enhancement or practiceBackground and NotesLearn More
Browser development tools You can use tools like Fiddler, Firefox Developer Tools and Chrome Developer edition to investigate the runtime performance of SmartForms. Video: How to investigate SmartForms performance issues
SmartForms runtime logging You can use the _debug query string parameter to enable logging output while a view/form is running. Append ?_debug=2 to the view URL, and review the log output while you perform actions in the form. This lets you see the sequence of rules that are executed. Debugging Forms
K2 application server logs You can enable and review the logs output by the K2 application server. This is  useful to troubleshoot internal server operations and determine if authentication is causing slower performance. Logging in K2
SmartObject Logging Logs let you see the data that was passed between the K2 server and the service broker. Enable logging for troubleshooting purposes, but remember to disable logging when you are done. Logging in K2
SmartObject Tester utility/Execute SmartObject from the K2 Management Site Use the SmartObject Tester utility (located by default at [K2 InstallationDirectory]\bin\SmartObject Service Tester.exe) to test the performance of a SmartObject without any UI overhead, (or alternatively you can execute a SmartObject using the k2 Management site, though that approach would add some web UI overhead).
This allows you to isolate performance issues to the form/view, or the SmartObject. Remember that a view can never execute faster than the underlying SmartObject method calls, so SmartObject performance tuning may also be required.
IIS Logging If needed, use the standard IIS log files to track individual requests. These logs can help to identify authentication issues and can isolate performance bottlenecks.

Other potential performance affectors

There may be other factors that affect the performance of SmartForms, including but not limited to:

  • Client Computer's Power Plan: If the client computer is set to a lower performance level in terms of the machine's power plan, overall performance can be affected. You can use the Power Options/Power Plans in Windows' Control Panel to adjust the power plan to a higher level of performance. 
  • Client-side exceptions or errors: Certain errors can delay or stop a page from loading. To view general JavaScript (JS) errors, open Chrome Developer Tools and go to the Console tab. JS errors appear in the list. If a request attempts to retrieve data that no longer exists, look for the error in the Chrome Developer Tools under the Network tab. This type of error stops the page from loading.
  • Non-production .dlls or services: debugging assemblies (for example an assembly sent in response to a K2 support ticket) can affect performance since they may not be tweaked for optimal production performance. Before you install a code fix, back up the affected files, in case the code fix introduces performance issues.
  • Browser Caching: If page loads vary across different browsers, browser caching and compression settings may be affecting the page load performance. Check the browser caching settings for the web browser on the client computer.
  • Caching Errors: Caching errors or settings can prevent effective caching. This means that the form is not stored in the cache. It is retrieved from the server and loads slower as a result because it must be loaded every time from the network instead of locally. Double-check the web.config caching keys to make sure that they are set to the defaults, and note any authentication or other exceptions that can cause caching problem.
  • JavaScript bundling: If the JavaScript (JS) loads using post-render combining, it means that it grabs all the script references after rendering and combines the requests into small batches. In certain cases, JS bundling/post-render combining issues can cause delays in page load. To determine if bundling causes the issues:
    1. Edit the web.config files for the applicable K2 smartforms site ([K2 installation Directory]\K2 smartforms Designer or [K2 installation Directory]\K2 smartforms Runtime)
    2. Set the values of the following keys in the web.config file to false:
      <add key="UseBundledFiles" value="false" />
      <add key="UseMinifiedFiles" value="false" />
      <add key="Forms.PostRenderCombining.Enabled" value="false"/>
    3. Restart the K2 server and perform an IISreset.
    4. Refresh the page. If the JS error disappears from the Console tab of the Chrome Developer Tools, it proves that something went wrong with bundling.

Additional Resources

Below are some additional resources that go into more depth or other aspects that affect performance in SmartForms.
ResourceContentsLink
Testing Results Compares the statistical performance of different versions of K2. Can be useful to detemirne whether an increase/ecrease in performance is related to a product version. K2 Performance Test Results by Version
Whitepaper Overview of capacity planning and management of K2 software to help you with capacity planning and management of K2 software. Performance and Capacity Planning Whitepaper 
Whitepaper K2 Center of Excellence whitepaper on Performance tuning SmartForms Performance Tuning Whitepaper