FC Performance Tests
⚠️ Historical baseline — not representative of the current stackThe performance numbers below were captured during the original GXFS-era implementation, on a stack that no longer reflects the running system:
- Then: Neo4j-only graph store, Java 11, on the pre-XFSC code line.
- Now: Fuseki as the default graph store, JDK and framework versions per the current
pom.xmland Dockerfiles. The verification pipeline, schema-module toggles, and admin layer added since are all unmeasured here.The figures are retained as historical reference only. Do not quote them as current performance characteristics. Re-baselining against the current stack is tracked separately.
We have the following performance requirements
| Acceptance criteria | Resolution/Status |
|---|---|
| All operations that are accessible from the public API can scale to at least 100 requests per second | One FC instance handles up to 90SD/credentialoperations and over 400 query operations per second. Four FC instances handle more than 300SD/credentialoperations per second |
| Catalogue must handle 100 read transaction of Self-Description per second | One FC instance can handle more, as the read/search operations are fastest inSD/credentialmanipulation scenario |
| Catalogue must handle 50 update transactions of Self-Description per second | One FC instance handles up to 90SD/credentialmixed operations (update + get/search) per second |
| Catalogue must handle 20 query transactions over the Self-Description Graph per second | One FC instance handles over 400 query operations per second |
| Self-Description Graph must handle the creation, update, and deletion of a singleSD/credentialin less than 2 seconds | On the small number of concurrent users FC handles all 5SD/credentialoperations in less then 1 second |
| The indexed graph must be capable of handling at least one million defined nodes, ten million properties, and ten million annotations at nodes or properties. | Not tested yet |
To support the requirements above we prepared two test scenarios:
- Self-Description Management - contains 5 steps withSD/credentialoperations (Add SD, Get SD by hash, Search SD by field, Revoke SD, Delete SD)
- Graph Query - contains one step with several queries in OpenCypher executed against Neo4J DB
Performance tests were developed and executed with Gatling. Test results are: perf_results.xlsx
The graphs presenting dependence of throughput and latency vs the number of concurrent users for these two scenarios are:
Query tests were executed on one FC instance with more than 20000 activeSDs/credentialsregistered.
Scalability tests were done with one, two and four FC instances onSD/credentialmanagement scenario. We see expected improvement in throughput and latency when number of instances increases.
The slowest operation fromSD/credentialmanipulation steps is SD addition, especially its SD verification part. We'll investigate how it can be improved.