Stream: hapi
Topic: Performance
Shlomy Reinstein (Feb 09 2017 at 07:32):
Hi,
Shlomy Reinstein (Feb 09 2017 at 07:34):
Trying to continue the thread here: https://groups.google.com/forum/#!searchin/hapi-fhir/performance%7Csort:date/hapi-fhir/0GJNC7kvCGQ/aESUJtiGCQAJ - hopefully more interactively.
A few questions:
1. Do you have performance numbers for HAPI FHIR?
Shlomy Reinstein (Feb 09 2017 at 07:34):
2. What is a proper way to exchange files with you? (showing the performance data we've collected and the test code)
Shlomy Reinstein (Feb 09 2017 at 07:35):
3. What features do you think may be configured differently / disabled / enabled to improve the performance of the server?
Shlomy Reinstein (Feb 09 2017 at 07:35):
Switching from 1.4 to 2.2, we've experienced a major improvement in performance of resource creation, but also a major degradation of performance of resource queries.
Shlomy Reinstein (Feb 09 2017 at 07:41):
The current performance numbers we get are not acceptable for our use case
Shlomy Reinstein (Feb 09 2017 at 08:00):
Shlomy Reinstein (Feb 09 2017 at 08:02):
Here's a sample of the performance data I got on my development machine. MySQL is used as the database of HAPI, and the test keeps running 6 concurrent threads. 3 of these threads create resources all the time (patients, diagnostic reports and observations), and the other 3 keep reading specific resources (using resource-type?_id=...).
Shlomy Reinstein (Feb 09 2017 at 08:03):
The average read time, in this test, for an Observation is nearly a second, and there are some spikes of 4.5 seconds.
Shlomy Reinstein (Feb 09 2017 at 08:03):
This test shows, however, that the read time does not depend on the number of resources in the system (which is expected).
Shlomy Reinstein (Feb 09 2017 at 08:10):
I found out that by completely disabling the paging support, the test results became an order of magnitude better, and are acceptable. (The test now only reads specific resources, so no use for paging).
Shlomy Reinstein (Feb 09 2017 at 08:11):
So I guess the paging support should be somehow tweaked.
Shlomy Reinstein (Feb 09 2017 at 08:11):
870714572.html
The results with no paging support.
James Agnew (Feb 09 2017 at 18:17):
Interesting.
I don't have shareable performance numbers at this point. We've run loads of benchmarks over time, and I've spoken to a bunch of others who have but I don't think we've ever kept them in shareable form. I'm curious about how you generated the results you shared? Is that automated in some way? Any chance the methodology is shareable?
The easiest way to send me stuff is to email me at jamesagnew@gmail.com . If it's too big for email let me know and I can share access to our secure file portal where you can upload bigger files.
In looking at the DatabaseBackedPagingProvider after the discussion on the list, and there is one thing I noticed- DatabaseBackedPagingProvider extends FifoMemoryPagingProvider which doesn't really make much sense, but it seems like that was just making up for a bug where _history calls weren't being paged to the database like they should be. I've just checked in a fix for that.
I'm baffled by your "nearly a second" time for reading an observation though. What type of load is the server under when you get that? Our public server reports response times in the < 10ms range even under load (e.g. this query ) . Is this a plain read you're doing? Certainly if you send your test harness my way I'm happy to see if I see similar results.
Shlomy Reinstein (Feb 12 2017 at 07:41):
Can you make the performance numbers shareable? Or are they confidential?
Shlomy Reinstein (Feb 12 2017 at 07:42):
We're doing plain reads. However, there are 3 concurrent plain reads, and at the same time, 3 concurrent resource creations.
Shlomy Reinstein (Feb 12 2017 at 07:54):
I have just sent you an email with the code of the test we run. It's a Maven project so you should be able to import it easily to most IDEs.
Last updated: Apr 12 2022 at 19:14 UTC
