Title here
Summary here
Performance Tuning
Parallel Processing
Pseudonymization requests can be processed in parallel. The degree of parallelism is controlled by the following configuration parameter:
| Name | Description | Default Value |
|---|---|---|
PSN_PARALLELISM_LEVEL | Number of parallel threads used for pseudonymization. Minimum: 1Maximum: 0.5 × number of available processors | 8 |
PSN_PARALLELISM_LEVEL=8Increasing this value allows more requests to be handled concurrently. However, it also increases contention on the database and CPU. The practical upper bound is capped at half the number of available processors to avoid starving other system processes.
Recommendations:
- For low-volume deployments, the default of
8is sufficient. - For high-throughput scenarios (e.g. large batch imports), raise the value in steps and measure database latency before increasing further.
- Setting the value higher than
0.5 × num_processorshas no effect — the service enforces the cap at startup.
Batch Interface
When pseudonymizing a large number of records, use the batch endpoint /v1/process/all instead of calling /v1/process repeatedly.
| Interface | Endpoint | Input | When to use |
|---|---|---|---|
| Single | /v1/process | One FHIR Bundle | Single-record or low-volume scenarios |
| Batch | /v1/process/all | List of FHIR Bundles | Bulk imports, initial data loads, high throughput |
The batch endpoint submits multiple FHIR Bundles in a single HTTP request. Internally, the service distributes the bundles across the configured parallel threads (see PSN_PARALLELISM_LEVEL above). This eliminates per-request HTTP overhead and allows the thread pool to be used efficiently.
Key properties:
- Each bundle in the list is processed independently — one failed bundle does not abort the others.
- The response is a list of results in the same order as the input.
- The same
targetSystemquery parameter applies to all bundles in the request.
For the full request/response specification and example payloads, see API documentation.