Optimizing the Backend: Examples of slow responses in O3

[tendomart (tendo kiiza Martyn)]

Thanks @ibacher from the observations above

1. Data compression using Gzipping (since most of our Rest and Fhir calls have proven to carry large amounts of information)

@ibacher

We definitely need some kind of guidance about setting up caching properly on the server, because the O3 frontend really depends on files being cached for a very long time to be performant.

2. Caching using a CDN of our choice for our frontends and a Redis cache for our Backend(am not sure how we would prioritize which endpoints to include

@ibacher

Right now, the query to get the list of concepts associated with Vital Signs looks like this: /ws/rest/v1/concept/?q=VITALS%20SIGNS&v=custom:(setMembers:(uuid,display,hiNormal,hiAbsolute,hiCritical,lowNormal,lowAbsolute,lowCritical,units)). This works, and it’s not per se a performance issue, but it only works on the assumption that there is just one concept in the dictionary named “Vital Signs” and that its a concept set. It would be nice if we had an API to request a concept by exact name.

How about pagination

Here are some of my findings using lighthouse

Home screen https://dev3.openmrs.org/openmrs/spa/home

Perfomance

Patient Dasboard performance and load time