Optimizing Data Import on Self-Hosted Medplum
# support
g
Hey Medplum team! Wanted to understand more the rationale for storing all the data as text fields rather than jsonb inside Postgres and whether or not there is any discussion towards using jsonb. We've been hitting quite a few performance bottlenecks where the write throughput is quite poor (ie. <50 / second). Our server and database are running on fairly beefy instances. I have yet to run a very comprehensive performance profiling but I've attempted to scale up medplum-server replications and it doesn't seem to improve performance by much Thanks!
r
Hi @Generaleoley it's a good question. There are a lot of different factors that can affect write performance, but we'll try to provide some insight.
wrt the JSONB - when performing searching / filtering, the Medplum server doesn't interact with the
content
column directly. Instead, we extract FHIR search parameters into separate search-parameter columns, which are indexed
Therefore we opted to avoid the transformation overhead in converting text to JSONB when writing
We would love more about how you're doing your scale testing, and what version you're on
We've made a number of performance improvements in 4.0.x, 4.1.x, 4.2.x, and 4.3.x that include a number of performance optimization
g
Thank you!
Will do! Give me a bit and I'll provide some more details
r
db size would also be helpful
g
The fork was taken off 3.1.6 so it's over 1 major version behind, I wouldn't be surprised if there was a significant amount of improvement since then. The main operations that I've ran that affected over 100k+ rows was: 1. Adding displays to the interperatations of around 250k Observations 2. Ingesting around 175k Communication resources All of these were done in large batch operations where I manually bumped up the max_json_size and disabled all rate-limiting I think for a proper profile I'm going to create ~100k dummy resources and ingest them both on our fork and latest upstream with the node profiler + pg profiler on and see what I find.
The DB itself is almost 1GB when I take a dump... not huge
r
THanks for the detailed readout. It's hard to diagnose these perf bottlenecks remotely, as there can be many different underlying causes, but I can point you in some directions to investgate
* A key metric we track is DB CPU usage and Server CPU usage. Check if any of htose might be saturating * You might want to try splitting your large batches into smaller batches and sendinf them in parallel. There are pros/cons to sending parallelizing batch import (better thread utilization) vs creating single large batches (better network utilization)
Yeah 3.1.6 is over a year old, so you may want to consider upgrading. We've made a ton of improvements in 4.x that will lower the DB impact of creates, updates, and searches
Also a bunch of new features for uploading groups of resources while maintaining references (e.g. Conditional References)
167 Views