Controlled performance test
This page documents one controlled Pritset template-processing test. It is a record of that run, not a production-capacity guarantee, service-level agreement, or measure of customer traffic.
What was testedโ
The JMeter test plan submitted POST requests to Pritset's direct template-processing endpoint:
https://api.pritset.com/api/template/process/direct/{templateid}
Each request supplied a template identifier and document data from a CSV data set. The result file labels all 1,000 samples as Process template.
Verified resultsโ
Results from a controlled test completed June 29, 2026. Performance varies with template complexity, document size, concurrency, network conditions, and deployment environment.
| Measurement | Result |
|---|---|
| Test date | June 29, 2026 |
| Template-processing requests | 1,000 |
| Errors | 0 |
| Sustained throughput | 16.26 requests per second (approximately 975 PDFs per minute) |
| Mean response time | 1.69 seconds |
The exported result file contains 1,000 successful samples with HTTP 200 responses. The exported statistics report records 16.2575 requests per second and a 1,693.37 ms mean response time; the table rounds those values for readability.
Test methodologyโ
The checked configuration and results support the following description:
- Apache JMeter 5.6.3 ran the plan.
- The plan used a thread group configured for 1,000 threads, a 60-second ramp-up, a four-second duration, and one loop.
- The enabled sampler used
POSTwith multipart form data against the direct template-processing endpoint. - A shared CSV data set supplied
templateidanddatavalues. Its delimiter was a semicolon and recycling was enabled. - The recorded result set contains 1,000 samples named Process template, each marked successful with HTTP 200.
The plan also contains a disabled image-processing sampler. It was not part of the recorded Process template result set described on this page.
Test environmentโ
The configuration identifies JMeter 5.6.3 and the configured Pritset API host. It does not record the load-generator hardware, operating system, geographic location, network path, target deployment version, server hardware, database or cache state, template complexity, template size, or document-data size.
Those details are therefore unavailable for this benchmark. They should not be inferred from the request count, response times, or host name.
Important limitationsโ
- This was one controlled run, not an SLA or a guarantee of production capacity.
- It does not establish how the service performs for every DOCX template, document payload, concurrency pattern, or network condition.
- The reported throughput is an observation from this configuration and run, not a commitment that 975 PDFs per minute will be available in another environment.
- No customer traffic, uptime, availability percentage, percentile result, or infrastructure characteristic is claimed here.
How to reproduce the testโ
Use the existing JMeter configuration and record a new result set rather than reusing this benchmark's result file.
- Use Apache JMeter 5.6.3, or record the exact version if a newer version is used.
- Configure a direct template-processing
POSTrequest with a dedicated, authorized test account. Provide the access token and secret through secure local configuration; never commit or publish credentials in a test plan or result file. - Prepare a semicolon-delimited CSV data set with
templateidanddatafields, and document the template and document-data characteristics used. - Configure the thread count, ramp-up, duration, loop count, and error-handling behavior. Save the exact values with the results.
- Save a fresh JTL result file and exported statistics report. Record the load-generator hardware and location, target deployment/version, network conditions, and relevant server telemetry alongside them.
Publishing those additional details with the next run will make the result easier to compare without turning it into a production-capacity promise.