0
0
0
0
Building applications is challenging. But creating fast applications is even more difficult. But Mendix simplifies application development thanks to its visual model-driven approach to developing apps and its numerous built-in, reusable components. However, one key issue that remains challenging to delivering an outstanding Mendix solutions application is response time and speed.
You might be wondering why we even care about response time and speed. The reason is simple; faster apps have higher chances of retaining and attracting new users. Since applications are built for different business purposes, including marketing the brand’s products and services, they are part of the company’s marketing strategy. So, how do we improve the Mendix app response time and speed? Here are the best practices for performance tuning with Mendix to optimize your app’s performance.
1. Avoid or Minimize Using Calculated Attributes
Calculated attributes execute each time a record is loaded. This is because retrieve activities always trigger the logic of these attributes. As a result, it leads to microflow calls and database actions being executed. Therefore, if your data containers, such as data grid, list view, or data view, use calculated attributes, it may affect your application load or response time.
How to Fix It
To solve the calculated attributes issue, do the following:
- Change the attribute to be stored rather than calculated in the domain model
- Whenever you’re about to commit an attribute to the database, calculate its value using the appropriate microflow
2. Create Indexes
You’ll likely encounter performance degradation whenever an entity contains more than 100 records. Creating indexes on such entities implies that records will be searched by anything other than Mendix IDs or references, improving your app’s response time.
3. Convert Qualified Microflows to Nanoflows
Usually, nanoflows are executed directly on the end-user’s browser or device. Therefore, they are perfect for offline usage. On the other hand, microflows operate in the runtime server, implying that they use network traffic.
Transforming eligible microflows into nanoflows helps minimize communication over networks, significantly boosting your application’s performance, response time, and speed. To identify the convertible microflows, use the following criteria:
- Microflows with nanoflow-compatible activities
- Microflows without the following variables: $latestHttpResponse, $currentSession, $currentDeviceType, $currentUser, and $latestSoapFault. These variables are not compatible with nanoflows.
- Microflows with one or more of the following classifications:
- Microflow with at most one database-related action.
- Microflow that has logic designed for offline applications.
- Microflow with logic is meant for online apps but doesn’t feature database-related actions, such as committing Retrieve, Rollback, Commit or Create object activities.
- Since nanoflows are executed based on the current user’s context, ensure the microflows you’re converting perform operations that the current user is authorized to access.
4. Avoid Caching Non-Persistable Entities
Non-persistable entities are objects that are considered temporary. These objects only exist in the memory. Therefore, caching them is never useful. It becomes redundant when you create relationships between non-persistable entities and System. User or System.Session.
However, it is crucial to cache objects that rarely change and are used frequently in your application logic. This helps prevent database communication overhead. Follow these guidelines to determine whether caching is necessary:
- Data is read frequently
- Data doesn’t change very often
- The impact of using stale data is acceptable
- The data volume is limited (less than 10,000 records)
5. Avoid Too Many Inheritance Levels
Using numerous inheritance levels and specializations on entities often affect your app performance on large data sets, mainly when using XPaths for entity access. This produces sophisticated queries and adds XPaths for each specialization access rule, leading to slow queries.
How to Avoid Multiple Inheritance Levels
Instead of using multiple inheritance levels or overusing specializations on your entities, consider these alternatives:
- Create entities with a one-to-one relationship rather than setting the generalization
- Create non-persistable entities that inherit from an outcome of your app’s business logic.
- Merge attributes in a single entity and add an enumeration rather than setting the generalization.
6. Avoid Duplicated Access Rules
Duplicated access rules on your entities affect your app’s performance, especially if you’re using XPaths for your entity access rules. Like in the case of multiple levels of inheritance, it generates more complex queries and adds extra XPaths for each specialization access rule, leading to slow queries on large datasets.
How to Avoid Duplicated Access Rules
Revisit your security rules, and don’t let your security model guide your process rules because the security engine isn’t optimized for process task management. Here is what to do to avoid duplicate access rules:
- Consolidate the variations in your rules and add extra checks in the microflows to verify state change instead of having all variations included in the access rules
- Secondly, try splitting your entity into multiple entities with one-to-one associations. These individual entities simplify the access profiles and possibly limit access to the whole entity instead of dozens of individual fields.
7. Don’t Use Deeply Nested List Views
List views are used on pages that are nested for multiple levels. For instance, a list view is inside a list view, and the second list view is within a data view. Deeply nested list views may interfere with your Mendix application’s page performance because of the increased transferred data volume and requests.
How to Fix Deeply Nested List Views
Restructure your current page and add a new one. For instance, you can add a pop-up page instead of nested list views.
8. Committing a Variable Should Be Your Last Action
Avoid committing variables to microflow repeatedly. A microflow with a frequently saved variable may lead to long-running transactions, impacting the overall performance of your Mendix application. To ensure variables are not committed often, refactor your microflows so that variables are only committed once in the flow.
Final Thoughts
Mendix application response time and speed are of utmost importance. It’s the only way to ensure users continue using the application as much as possible and new users are attracted to try the app. Considering these performance-tuning best practices with Mendix can help you build apps with great response time and speed to impress users.
So, why wait? Start practicing and creating super-fast applications with Mendix today and deliver unbeatable customer experiences.
