AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
10th May 2019
Optimising Mendix objects to avoid unnecessary application downtime
I have been supporting Mendix applications for more than two years and application downtime caused by mismanaged Mendix objects, is one of the biggest problems we face when ensuring Mendix applications continue to run in an efficient and stable manner. We are always looking for ways to maximise the uptime of an application and limit any potential problems, before they cause potential outages for an end user. Lack of garbage collection is one issue which continues to crop up, time and time again.
The problem
When developing applications for a client using agile methodologies, sprints focus on system requirements, end user experience and overall functionality. Rarely is a system designed with the database space constraints and application life expectancy as the greatest concern and this can ultimately affect the future use of the application, years down the line. When this is not taken into consideration, it can lead to bloated database tables, thousands of redundant data table entries and leftover objects which are no longer required. In the worst-case scenario, this can cause the database to quickly become full and will ultimately take the system down. At this critical point, a client’s only option is to either incur the cost of increasing their database space or find a way to clear down data ad hoc. If the application is housed in the Mendix cloud (and not housed on premise), this can become troublesome. By using garbage collection, we can prevent this from happening entirely by using scheduled clean up events and applying left over object deletion within Microflows.
Main considerations
Application longevity: How long the application is expected to be in place and will this affect how data should be stored and managed within Microflows? If the application is set to be in place for five years, then keeping large amounts of objects could cause issues in the future.
Database space constraints: How much space do you have to work with? If the business cannot incur the cost of upgrading the database space, then this can greatly affect how objects, files and general data must be managed in Mendix Microflows.
Business requirements: How long do files need to be kept? How long do objects need to exist for? This comes into play as some businesses will be required to fully audit certain information and therefore these objects need to be protected for a certain period of time before deletion. For example, if a PDF is generated and exported by a Mendix application and sent into a downstream system, it might be best for the PDF ‘file’ to be kept for six months. If any issues arise in finding this PDF file in the downstream system, then the information is still available in the Mendix application for audit and investigatory purposes. Keeping a PDF file any longer could use up valuable space.
The Solutions
The three main possible solutions are all achieved during development of the Mendix application and will need to be considered as the application is being built. The below suggestions are largely achieved through Microflows, domain model setups and scheduled events.
Clearing up data with scheduled Microflows
The best option for data that needs to be kept for a certain period of time, involves creating a Microflow that will delete information that no longer needs to be kept by the application. This is then scheduled to run based on the businesses requirements. When building the foundations of the application, database space constraints and business requirements should be considered and clear up Microflows should be included to remove unwanted information, where appropriate.
Maintaining ‘good’ object deletion rules
Deletion rules when set up correctly within the domain model, will ensure that less orphaned data is left over when a related object is deleted. Good deletion rules are ones which consider what is going to be made redundant if its counterparts (those which it has associations with) are cleared down. To spot bad deletion rules, look for restrictions which don’t need to be in your domain model – if you are restricted from deleting an object purely because it has an association then consider if this is the correct method to take. Below is a straightforward example of where we would need to implement a delete object rule. Here we have a ‘to do list’ object that is associated to many ‘items’. If within the application we want to delete a ‘todolist’, then we need to ensure that we use deletion rules to clear down the redundant items, which could have been left over if we only deleted the ‘todolist’ (with no deletion rule).
It’s always best to check these rules for any objects you are deleting in a scheduled event, as this will ensure you are not leaving behind isolated data.
General object deletion
If you are simply using an object once to set another and it’s committed in the Microflow, and it never gets used again on any pages or objects in the application, then that object would be an ideal candidate for deletion at the end of a Microflow or in a scheduled event. If this microflow has a high run volume, then this redundant data would always find its way into the database increasing table sizes if you don’t take into consideration its run counts and place deletion actions where appropriate.
‘Bloat’ in your Mendix database
Particularly with applications which create and delete large quantities of data per day (and are hosted on the cloud), no matter how careful the developer is with ensuring the data is efficiently managed, there can be bloat in the database tables (and indexes). In time, this can affect the performance of database queries and, ultimately, the application health. Mendix – “The primary reason for this is that even when you delete records from the database, the physical space on the hard disk is not freed up. Instead, the now empty records are kept in place so that they can be reused once new records are inserted (created) into the database.” This can sometimes be temporarily resolved by stopping the problem application, taking a backup and then restoring that backup onto the same application instance. This might seem purposeless, but this will recalculate the amount of space which is being set aside for future use and free up space. For full details on this please see here. This should always be performed with caution, as some extra space is required to perform this task and it is best to check with Mendix before going ahead with any task that has this much risk associated.
Final note
A functional and efficient application which is required to handle a large amount of data cannot be created without first considering the above solutions, as making an allowance for these will ensure that your application should remain healthy in regards to database data allocation – whether it be six months or two years down the line.
Related Blogs
Drag