You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are running these services using docker-compose, and are running into some pretty severe responsiveness issues when making requests for FHIR Resources.
We noticed that the CPU usage goes up past 100% when processing even a few (<10) concurrent requests.
We attempted to increase the memory allocation and CPU limit by editing the .env file entries as suggested in the documentation, but this led to the same very high CPU utilization numbers as measured by the CLI tool top.
We even increased the scale of the VM we have running the container images to an 8 core, 32 GiB machine in our cloud provider, and increased the .env flags to use 90% of that RAM and all of the CPUs.
The results were still as depicted in the attached gif - individual resource requests are taking multiple seconds to process and return to our application, during which time the CPU utilization spikes to over 100%.
Is this server intended to be able to process even a few concurrent requests?
We also changed the strategy of our application to use sequential requests - i.e; each Resource request's response was awaited in our application code - only sending the next Resource request once the current one had been completed by the server and returned to and processed by our application.
Should we expect that requests sequential requests for even a few Resources be this unresponsive? (sometimes it takes 15-30 seconds to process 6 Resource requests). Is it possible the underlying standalone hapi-fhir server is responsible for the slow response time?
Thank you.
The text was updated successfully, but these errors were encountered:
Hello,
We are running these services using
docker-compose
, and are running into some pretty severe responsiveness issues when making requests for FHIR Resources.We noticed that the CPU usage goes up past 100% when processing even a few (<10) concurrent requests.
We attempted to increase the memory allocation and CPU limit by editing the .env file entries as suggested in the documentation, but this led to the same very high CPU utilization numbers as measured by the CLI tool
top
.We even increased the scale of the VM we have running the container images to an 8 core, 32 GiB machine in our cloud provider, and increased the .env flags to use 90% of that RAM and all of the CPUs.
The results were still as depicted in the attached gif - individual resource requests are taking multiple seconds to process and return to our application, during which time the CPU utilization spikes to over 100%.
Is this server intended to be able to process even a few concurrent requests?
We also changed the strategy of our application to use sequential requests - i.e; each Resource request's response was awaited in our application code - only sending the next Resource request once the current one had been completed by the server and returned to and processed by our application.
Should we expect that requests sequential requests for even a few Resources be this unresponsive? (sometimes it takes 15-30 seconds to process 6 Resource requests). Is it possible the underlying standalone hapi-fhir server is responsible for the slow response time?
Thank you.
The text was updated successfully, but these errors were encountered: