Hello,
I have done some test, to see if can find out what caused the long wait
time for first time requests. Here are some findings:
- The first time requests always seem to take 60 seconds and a bit (e.g.
60.232 seconds). So every time it is suspiciously close to a full minute.
- The subsequent requests take less than a second (e.g. 0.109 seconds).
- The effect still occurs when I restart Marmotta between first and
subsequent requests.
- I tried turning off versioning (*versioning.enabled*). That did not
seem to have an effect on response times. The response headers did still
include timegate and timemap links, which I don't understand.
- Of the settings that can be changed using the admin web UI, I saw the
setting *ld_cache.so_timeout *is the only thing set to 60 seconds (60000
miliseconds), which could somehow have to do with the delay of a bit more
than 60 seconds for a first request. To test that, I tried changing the
value of 60000 to something else. But I was not able to save the change
because of an error: cannot store content: TypeError:
value.getValue(...).split is not a function.
- Disabling ldcache altogether (*ldcache.enabled*) did solve the problem.
So I was able to solve the issue by disabling caching of remote resources.
That was unexpected, because all resources I requested where not remote but
local. But perhaps the problem lies with the way in which local and remote
resources are discerned, I do have some URI rewriting configured (I wrote
about that in another thread).
The Linked Data Caching Module looks like a useful Marmotta component, it
would be a pity if I can not use it.
Would it make sense or be useful if I log my findings in the issue tracker?
Or can everything be easily explained?
Greetings,
Frans
On 23 August 2016 at 11:03, Frans Knibbe <frans.kni...@geodan.nl> wrote:
> Hello,
>
> I wonder if the following can be explained... I run Marmotta 3.3.0 with a
> PostgreSQL 9.5 data store. I notice that when I request a certain resource
> the first time it takes a long time (more than a minute) to produce the
> reply. Subsequent requests for the same resource are resolved quickly (less
> than a second). Perhaps I should mention that resource requests are
> rewritten to {BASE}/resource?uri=<resource URI>.
>
> If I recall correctly, the effect was less or absent when I used the
> default H2 data store.
>
> Is some kind of caching going on? It seems that the effect is not caused
> by browser caching or by PostgreSQL's cache.
>
> Is there something I could do to remedy the effect?
>
> Greetings,
> Frans
>
