Performance Issue with $expand and filter in Snowstorm FHIR Terminology Server

[sureshg7254]

Hi Snowstorm Team 👋,

I'm working with the Snowstorm FHIR terminology server and have successfully uploaded SNOMED CT RF2 files, as well as LOINC and ICD-10 ZIP archives.

We’ve configured the Java heap memory to 4–8 GB, Elasticsearch with 6 GB of memory, and provisioned 4 CPU cores.

While using the $expand operation, we’ve observed that responses are significantly slower when using the filter parameter. For example, without the filter, we receive a response in under 200 ms. However, with a filter applied, the same endpoint takes approximately 4–5 seconds, even with count=10.

Here’s an example API call we're testing:

/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/<<105590001 OR <<418038007 |Propensity to adverse reactions to substance| OR <<267425008 |Lactose intolerance| OR <<29736007 |Syndrome of carbohydrate intolerance| OR <<340519003 |Lysine intolerance| OR <<190753003 |Sucrose intolerance| OR <<413427002 |Acquired fructose intolerance| OR <<716186003 |No known allergy|&filter=sur&count=10&offset=0

Ideally, we expect the filtered response time to be under 500 ms. Could you please advise on how we can optimize performance for $expand operations using the filter parameter?

Looking forward to your guidance!

Thanks & Regards,
Suresh Gedela

[kaicode]

Thank you for trying Snowstorm and reaching out with your findings. This sort of feedback is very valuable and helps the community.

Could you please measure the performance of the first and second expand request after a Snowstorm restart. Keep using the same ECL query.
Try changing the filter text and let us know if that affects the performance of subsequent requests or not.
Let's continue the conversation after that.

[sureshg7254]

For the below expand request with filter=sur

/fhir/ValueSet/$expand?url=http://snomed.info/sct?fhir_vs=ecl/<<105590001 OR <<418038007 |Propensity to adverse reactions to substance| OR <<267425008 | Lactose intolerance | OR <<29736007 | Syndrome of carbohydrate intolerance | OR <<340519003 | Lysine intolerance | OR <<190753003 | Sucrose intolerance | OR <<413427002 |Acquired fructose intolerance | OR <<716186003 | No known allergy |&filter=sur&count=10&offset=0

For first time it is taking 1.63 seconds, and second time it is taking 1.40 seconds

• And I tried with different filter values filter=abc, I am getting quick response( avg. 250ms)
• And I tried with different filter values filter=fever, I am getting response in avg. 400ms
• And I tried with different filter values filter=head, I am getting response in avg. 750ms

Based on filter text, the performance is varying.

[kaicode]

When expanding ECL with a text filter Snowstorm will aggressively cache the exhaustive set of all concept ids that match the ECL statement. This takes some time depending on the size of the unfiltered ECL results. Then the text filtering will be applied in a second stage.

When another request comes using the same ECL query on the same CodeSystem (Edition and release) Snowstorm already has all the concept ids cached so only the text search needs to be applied.

If you still need more speed consider giving Elasticsearch a faster disk and hosting Elasticsearch and Snowstorm on the same machine if they are not already.

[sureshg7254]

Okay, i will modify configuration & check the performance and get back to you. Thank you @kaicode