On 23/11/2021 22:23, Andy Seaborne wrote:
On 23/11/2021 19:54, Philipp Leeb wrote:
Hey Rob,
thank you for this information. Yes, i tracked times of respones and
registered, that the first queries are always the slowest, which made
me think there is some sort of caching.
More likely it is
(1) [TDB] The database getting loaded on-demand.
(2) The JVM JIT compiling code
(seen that rob has said the same - (1) is more noticable when serving
the database off a rotating disk)
It is unlikely to be any reverse proxy because normally reverse proxies
do not cache GET request with query strings. Fuseki responses should be
set to "don't cache" at the HTTP layer as well.
Andy
Greets,
Philipp
-----Ursprüngliche Nachricht-----
Von: Rob Vesse <rve...@dotnetrdf.org>
Gesendet: Dienstag, 23. November 2021 20:49
An: users@jena.apache.org
Betreff: Re: Embedded Fuseki Cache
No it's not, no version of Fuseki, or any other Jena library,
currently offers SPARQL Query Caching
I presume there is some behaviour you are seeing that would lead you
to suspect caching?
There are a bunch of things going on both with the underlying TDB/TDB2
database layer that does include some caching of low level data
structures. This is below the level of SPARQL queries themselves but
running the same query repeatedly would use these caches on subsequent
requests that could cause subsequent queries to run faster.
Also if this is a cold JVM start then there are JVM class loading
overheads for the first few queries you run as various classes are
loaded that can also cause initial queries to be slower than
subsequent ones.
Rob
On 23/11/2021, 19:02, "Philipp Leeb" <p_l...@t-online.de> wrote:
Hey guys,
i have a question: is embedded Fuseki caching SPARQL queries? And
if so, is
there a possibility to disable it?
Kinds regards,
Philipp
