Designing for Performance: Troubleshooting Poor Responsiveness
When moving your LogicNets applications from design and development, to test, and then to production, you want the overall performance of the system and user experience to be responsive. This topic includes information about decisions to consider as part of your design as well as troubleshooting tips if you find the system interaction is sub-optimal.
Also look at this article for information on how to use the Performance Analyzer application to review the timing of specific processes, nodes, and parts in your logicnet model.
Design for Performance
- Simplify Application Logic
With LogicNets, there are often multiple ways of achieving a similar UI result, but some affect performance more than others. For those areas of the application that are more process intensive, think about the most efficient way to model the logic from a performance standpoint.
For example, with reporting logic, break up large processing steps by writing single records to your report tables as each transaction is edited, rather than processing all records each time a user accesses the reports tables. - Clean up the Context File through the Model
The LogicNets engine holds the values of user inputs and calculated logic in the context, and you often access these using the DATA button during design and development. The larger the context file, the harder your application has to work on each click. Good practice is to "clean up" any temporary variables, get records collections, etc. after they have served their purpose in the logic, by deleting the variable after processing. You can review your context file in a trial run of your application and then using delete steps to keep it as streamlined as possible. - Improve SQL Queries, Tables, and Indexing
If your application involves using our template Starter App to save and restore sessions, or if you are managing larger data sets, your application may be executing database queries on save or during the execution of logic. To reduce the performance load in this case, think about the following:- You can index tables on key fields, and configure them for better response to multi-user access where appropriate.
- To improve updating speed, you can separate large "BLOB" files that hold session data from tables used to populate user screens.
- You can expedite temporary access and processing of table data using "session" tables, which are unique copies of a table reserved for a single user.
- For multi-user applications that are writing to SQLite tables, implement the WAL setting (Write-Ahead-Log).
- Manage Users and Usage
You will have purchased licenses for runtime use, but how will users interact with the system? Will all users be using the system throughout business hours? What is the expected concurrent user count? How intense is the usage? Will there be a heavy click rate as users whistle through quick yes/no assessments, or a slow click rate as users read detailed questions and consider responses? - Clean up Session, Log, and Trace Files
See this article for more information on how to clean up these system files on a more frequent basis. The default is set to 7 days of history. The process runs once per day at the original installation time. - Do Not Use the Changelog
Some of our products, such as the LogicNets Assessment Framework, are equipped to log field entries and corrections to provide a full audit trail of user interaction. When enabled, this involves writing inputs or events back to the changelog table on each click, which requires system resources. Turning this off when not required will enable the system to bounce back quicker. See the article on Assessment Framework Project Settings for more information. - Production Installation Specs
Whether your installation is on-premise or hosted, there are some key decisions in terms of set up that will have a direct impact on your application's performance. Some of the most important decisions are around CPUs and hard disk space. The LogicNets team can help you with this.
Talk to your LogicNets Representative about all these topics above when your application is taking shape and your launch is not too far off. We can help you with specific techniques and configuration that can be done to build a fast-performing application.
Troubleshooting Poor Responsiveness
If your application is live and users are experiencing system slowness, system busy messages, or other problems, the tips below will help you troubleshoot your application.
- CPU Utilization
If you are seeing CPU usage spike about 80% for prolonged time (15 secs or more repeatedly) then you may insufficient resources for the application AS DESIGNED. Try increasing CPUs even in the short run, just to provide more capacity. Once other actions are taken to address system inefficiencies, you may be able to reduce CPUs again. - Hard Disk Space
A system running close to the maximum disk space will struggle to process larger data sets. Try increasing disk space until other actions are taken to address system inefficiencies. - Concurrent Users
Check whether the performance improves at the end of the business day (or when fewer users access the system). Organize a quick test starting with a single user and adding additional users every few minutes to see if there's a degradation in performance. - Processing
Look at the logicnet activities being conducted on the system. Filtering non-indexed tables or frequent writing to large data tables can slow the system down. - Data
Check for rogue data that might have been created by a corner case defect in your logic. Look at the size of session files, the size of your Starter App db overall, and the data blob for each record.
Don't forget that LogicNets applications make round trips to the server on a frequent basis, so any network, firewall, or infrastructure issues within your corporate IT set up or in the public domain will impact the responsiveness of the application. Check that any performance issues are specific to the LogicNets application before contacting your representative or logging a support ticket.