@janflowers I would vote for working on individual tickets as these things are discovered.
For the https://test3.openmrs.org/openmrs/ws/fhir2/R4/Location?_summary=data&_count=50&_tag=Login+Location call that @lumuchris256 listed in his report, my recommendation is that we change it from using FHIR to the end point provided by the webservicesrest module: https://test3.openmrs.org/openmrs/ws/rest/v1/location?tag=b8bbf83e-645f-451f-8efe-a0db56f09676&limit=50
This call is already 4 times faster than the FHIR one. And i have just made a commit to make it 2 times faster, than what it already was, with this ticket: [RESTWS-934] - OpenMRS Issues hence eventually making it 8 times faster than the FHIR one. Which, on my computer, while connecting to a local O3 backend, translates from an average of 300ms to 35ms.
And when a custom representation of something like custom:(name,uuid) is used for the webservicesrest end point, it will also save on the bandwidth, as less data is sent over the wire.
The performance problems of the FHIR end point are caused by these two lines below during the translation from OpenMRS to the FHIR format:
This results into extra unnecessary database calls for each location that is returned. With the _count=50 parameter, it means 50 * 2 = 100 extra database calls.