Link generation can be expensive on datasets of specific shapes. It may be possible to mitigate/reduce this somewhat. At the least, as the generated links are cached, it is surprising to see large numbers. It would be expected that numbers closer to those for annotations can be achieved.
Numbers from a Fuseki deployment on Azure to provide context to optimisation targets:
| phase |
event |
ms |
share of total |
share ex-Fuseki |
CPU or I/O |
| pre-query: construction + profile + CQL + FastAPI |
request_complete − listing_function_complete |
87.7 |
28% |
51.4% |
CPU |
| link generation |
listing_link_generation |
62.8 |
20% |
36.8% |
CPU |
| render |
listing_function_complete.render_ms |
11.6 |
4% |
6.8% |
CPU |
| annotations, warm |
return_from_graph_annotated_oxigraph |
8.4 |
3% |
4.9% |
mostly cached |
| subtotal, addressable |
|
170.5 |
55% |
100% |
CPU |
| Fuseki round trip |
listing_query |
146.7 |
47% |
excluded |
awaited I/O |
| total |
request_complete.total_ms |
312.4 |
|
|
|
Although these numbers are specific to one (real) query, and database, optimisation against this is likely to benefit other DBs/queries generally.
Optimisation of the query construction is raised in #473
Link generation can be expensive on datasets of specific shapes. It may be possible to mitigate/reduce this somewhat. At the least, as the generated links are cached, it is surprising to see large numbers. It would be expected that numbers closer to those for annotations can be achieved.
Numbers from a Fuseki deployment on Azure to provide context to optimisation targets:
request_complete−listing_function_completelisting_link_generationlisting_function_complete.render_msreturn_from_graph_annotated_oxigraphlisting_queryrequest_complete.total_msAlthough these numbers are specific to one (real) query, and database, optimisation against this is likely to benefit other DBs/queries generally.
Optimisation of the query construction is raised in #473