Improve performance by splitting page / reducing database calls for drop downs by caching drop down entities

Hi All,   I am stuck with one issue where I have one very large page which contains Accordions(8-9) to separate registration page into different sections. We have multiple drop downs used on these sections throughout page and it increases database requests which is causing slowness with more concurrent users. These drop downs are implemented using custom drop down – reason :-  We need drop down with partial search and Accordion do not support most of the drop down options like auto complete, etc.   Now I want to know how can we improve the performance like by splitting the page is one out of it. There are so many XAS calls while working with this page but we have already worked on most of the recommendations like : Instead of association use microflow as source for data views as refresh in client impact associations as well(indirectly affects other data views where associations are used). Wherever possible, use Nanoflows instead of microflows.   But I would like to know how can I cache data for these drop downs in application /maybe by using JVM memory if I can cache drop down source entities ? Any marketplace module to cache data throughout the sessions for all users ? or any other option to do same ?   
1 answers

Not to be rude, but let’s start with something a bit simpler. Caching is a hard problem. Caching data in the mendix runtime would very much be an anti-pattern as the server is stateless in nature. While you could theoretically use an in-memory database in another process, you’d still need to marshall data back and forth between your Mendix app and your caching system.


In this custom widget, what type of delay do you have in the auto-complete / type ahead feature? Are you canceling previous events? Doing that incorrectly could also cause extreme load on your system and emit a lot of unnecessary XAS calls.