In this article, you will find information on how you can manage your Knack app's performance.
We’ve designed Knack to reflect the reality that data can be messy, and that everyone will use data in different ways.
This means favoring open-ended tools that empower you to accomplish your data goals, rather than constantly blocking you with restrictions or limits.
We view this flexibility as a tremendous strength of the Knack product. However, like most strengths, it can also be a weakness.
In Knack’s case, it can lead to apps that can get really complex. This complexity can lead to computational requirements that can impact the performance of your application.
For example, consider the following scenario:
- You want to track employees who sell things, and you want to calculate a commission for each sale.
- Each employee is connected to a company, and to all the sales they make.
- You calculate a commission for every employee by multiplying the company rate (say 10%) by the sales revenue.
- That company rate is stored in the company table connected to every employee. That way you can change that once and see how it affects every commission.
Now, let's say that you update the company rate. That single update needs to go through every employee and every sale and recalculate those commissions.
Potentially, thousands of those employee records will need to be updated to reflect that single company change. In this scenario, the sales records are dependent on the company records.
That’s a simple example, but now imagine if each of those commission records has its own dependencies. You could be looking at hundreds of thousands of computations that need to happen before that record update can complete.
If you have tasks that then update thousands of company rates, now you're looking at further exponential processing requirements. It’s scenarios like these - where updating one record triggers thousands of other record updates - that can dramatically impact performance.
We want you to be aware of what can lead to this complexity, and what you can do if complexity starts to impact your app’s performance.
What impacts the complexity of my app?
The following are common scenarios that can impact the complexity of your application and have the potential to impact performance.
What makes an app complex?
- Number of rules and how complex they are
- Number of equations and how complex they are
- Number of formulas
- Number of records/images loading on pages
- Number of views loading on pages
Cascading operations happen when rules, equations, and formulas are used in succession. This means a single action in your app can trigger a wave of other processes throughout your app adding to the complexity.
For example, one record update can trigger a formula update, which triggers further formula updates, etc.
Rules and Performance
What types of rules affect performance?
- Record Rules, Conditional Rules, and Validation Rules
- These rules require records to be processed after updates.
- Display Rules and Page Rules
- These rules affect page load speed. However, have a less widespread impact on app performance.
How many rules are too many?
To keep Knack open-ended and flexible, we don’t enforce a limit on the number of rules you can add. However, each rule can vary in complexity, and it is up to you to choose what is reasonable for your app and expectations.
The more rules you add within your app, if those also involve cascading operations, the greater the impact those rules will have on the performance of the app, views, or pages. Since each app has its own setup and workflows, it is hard to provide a number of rules that will keep your app performing at the same level.
However, in general, the more operations rules trigger on other fields or connected tables, the more time it will take to process those operations thus impacting the performance of your app.
Note: Avoid depending solely on record rules in a form. Instead, enhance the speed of your form by leveraging text formulas, equations, and conditional rules to distribute these updates.
Learn more about rules in the following articles:
Equations, Formulas, & Performance
Why do equations & formulas affect performance?
Each time a record is touched by an action (such as, updating a record) this will create a job to process any changes in equations or formulas.
For example, if a form updates a batch of connected records, each with 20 equations, a job will be created for each of those equations which have to be processed for all of the records in that batch.
How many equations and formulas are too many?
Similar to rules, to keep Knack open-ended and flexible, we don’t enforce a limit on the number of equations and formulas you can add. However, each equation and formula can vary in complexity, and it is up to you to choose what is reasonable for your app and expectations.
A few things to consider about equations and formulas:
- Cascading operations (record update triggers a formula update which triggers another update, etc.) is the primary reason a large number of equations and formulas can contribute to your app’s complexity.
- Combine equations or text formulas where possible: Don't use several equations and combine them together into a single equation at the end. Try to combine all of that into one equation.
- Remove unnecessary equations and formulas: Ensure that unnecessary equations and formulas are removed if they are no longer used.
Learn more about equations, formulas, and text formulas:
Views, Pages, & Performance
Number of Views on a Page
The number of views and the level of complexity of those views can impact page performance in the Live App. In short, the more views on a page the more your browser has to load.
- A page with 5-10 simple views with little filtering is reasonable.
- A page with 5-10 complex reports can make the page load slower.
- A page with 20 views? Yikes, this will contribute to poor user experience and performance issues.
Records and Images in Views
The number of records or images displaying in views can impact page performance in the Live App. The more records or images being displayed on a page, the more your browser has to load.
- A view with 10 records and 10 images, that's easy to load.
- A view with 1000 records and 1000 images, that's a lot of data!
Tip: Adjust the default pagination settings to display a lower number of records when the page loads.
What happens if I notice performance issues with my app?
When you suspect that the complexity of your app may be impacting your app’s performance, the first step is to understand what is leading to that complexity.
Evaluating your app in light of the scenarios described above is a great first step. For example, if you have a form that takes too long to submit, try to think of any connected equations it may need to update before it can be completed.
Our support team can also help here if you can provide processes in your app that consistently show poor performance. We have internal tools that can help shed light on the overall complexity of your app and highlight possible areas of mitigation.
With this, we would hope to point you in the right direction as you work to reduce the complexity of your app.
Once that complexity has been confirmed, there are three basic options to consider.
- You can try to reduce the complexity of your application.
- You may need to consider paying for additional resources to meet your performance goals.
- You can split your single complex app into multiple different apps. However, it is important to note that apps cannot be connected and share records or users.
How can I reduce the complexity of my app?
The following are some approaches that can help reduce the complexity of your app:
- Equation and text formula fields: Are they all necessary; are there other ways to reference the information? Can some be combined?
- Formula fields: Can any of the formula fields such as sums, counts, etc. be set up via report views?
- Connected records: Where can pages and views be used to display connected information? Rather than using formulas, equations, or other fields to pull this information into one table.
- Pages and Views: Are there extra pages that are unnecessary, or could page rules be used to display different information to different user roles instead of several pages that recycle the same information?
- Form rules: Are there inserted connected record rules that then trigger a cascade of other field value updates on connected fields that could be removed or simplified?
- Tables, fields, and connections: Are there extra connections between tables that aren't needed? Fields that are no longer used?
- Records: Sheer record count typically doesn't drastically bring the app to a crawl, but if they aren't being used, could historical records be exported and removed?
- Split up your app: Are there multiple standalone workflows or processes happening within a single app? For example, are you using a single app to manage customer orders and job applications? Are multiple departments/teams using the same app?
Caution: Please be sure to create a copy of your app to test these improvements before making any significant changes.
What if I need to improve performance without reducing my app’s complexity?
It’s possible that you can’t reduce the complexity of your app without compromising the business goals that your app was designed to accomplish.
In these situations, isolated resources on an Enterprise plan may be able to help. One of the biggest benefits is eliminating the potential for other apps to directly impact your app's performance.
Isolated resources also provide some of the following benefits:
- Higher Job Concurrency - Other app jobs can't block your jobs.
- Increased Calculation Limit on Formulas - 10k to 100k.
- Database Index Optimization - Can provide major performance gains in scenarios that result in many repeated database queries.
Note: Please reach out to our support team to find out if isolated resources can help improve your app's performance.
Why is this my problem? Can’t you just design Knack better?
If only it was that easy! Yes, this is certainly what you’re paying Knack to do, and we’ve devoted thousands of engineering hours to tackle this exact problem, and will continue to do so.
We apply caching, batch processes, indexing, parallel processing, and every other trick we can think of to make things as performant as possible.
Ultimately, we’re facing the fundamental challenges and limitations that come with any database design, and most of our improvement can only come at the margins. Consider those dependent calculations: there’s only so much we can do when we have to wait for one calculation to complete before we can update further calculations that are dependent on it.
These are challenges that professional computer engineers writing custom software from scratch will struggle with. At some point, this literally gets down to the laws of physics: computer bits are getting switched, and that can only happen so quickly.
Regardless, we are committed to constantly improving performance and will do everything in our power to ensure that this is something you never have to think about.