Just to share info with other SFX administrators…
I discovered a weird problem a few months ago, with a request to SFX for a certain pmid causing my SFX to reproducibly timeout.
Some more answers to the mystery came from an SI I filed with Ex Libris, although I think the resolution is still a bit disturbing.
It seems that in some circumstances, SFX will perform a pmid lookup for every “related object” related to an object involved in the request.
In the problem case I ran into, there were over 200 related objects. Which meant SFX did over 200 seperate NLM api lookups behind the scene. Which, on my server, meant that the SFX page could take 5-10 minutes to return. Which is obviously no good, it might as well not be returning
at all, no user will wait 5 to 10 minutes for a web page.
To make matters more ridiculous, in this case, all 200 NLM api lookups were for the same pmid. So, as far as I can tell, all these lookups were identical, SFX got the same response back from the NLM each time, but still makes the request over and over again, getting the same response from NLM each time.
I suggested that this was a bug, there’s no reason for SFX to make the same request to NLM 200 times for an SFX request. But EL support suggested this was not a bug, this was planned/expected behavior, and they did not consider it a bug to be fixed.
Which I find unfortunate, but just updating you all.
Where exactly this demonstrates may depend on your local KB, but for me it can be reproduced with pmid 20405364. I’d be curious if other people can reproduce terrible SFX response times for this pmid, with a request including a context obj like this:
I would be especially curious how Ex Libris-hosted SFX instances do with this context object.
If somehow only my server exhibits the problem behavior, then maybe there’s something I can change in my server to resolve it, although I’ve been unable to figure out what, and EL support had no suggestions.