I am wondering if there is any suggestion on speeding up the loading of the dashboard widgets, since the core is now moving to REST calls. There are about 40 AJAX calls to load the data for the different widgets
Do we tweak Tomcat? The database tweaks are innodb_buffer_pool_size which is already at 40% RAM for a Windows server so the database fits in memory.
This page takes about 20 seconds to load, which becomes an issue for clinicians using it. Any suggestions for further profiling to find the bottle necks?
My first thought, if this page requires 40 ajax calls, is that it must be making multiple calls per widget, and these should be combined.
In other words introduce a new rest resource for each widget that currently makes multiple calls. The new resource may make multiple Java API calls, but combines into a single rest response.
(You could think of this as the back ends for front ends pattern, in other words it’s appropriate for the ref app to provide these rest controllers in the core apps module. there might also be an argument for doing this directly in the rest module, but I’m not certain about that.)
Or maybe some of these widgets could query the reporting module.
So we need to restructure all the components which are connected to this Dashboard to make this combined REST calls.
Or else, Can we direct all the REST calls from this widgets through a intermediate communicator (may be JS based communicator), and store the responses in a short memory storage(unique for the patients or calls). Then the communicator should return the stored response data to the caller if the requested REST calls is points to exiting one. Using this way, We need to implement a intermediate communicator for this widgets and no more major chances for the widgets or REST resources. Is it possible to make it?
Unfortunately you cannot cache the calls, as these are to data that can change at any time. It will be too much work to have to invalidate caches.
This is an excellent idea, which will certainly speed up the calls e.g., latestobsforconceptlist makes a REST call for the latest obs for each concept specified in the list. If this is mapped to a single REST interface then a single call is made irrespective of the number of concepts specified.
For this specific example (get latest obs for multiple concepts for a patient), this seems worth adding to our core REST module. But it would require some extra design there, so you should probably do the quick-fix in the coreapps module first.
