unfortunate SFX behavior with some pmid lookups

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:

?sid=Entrez:PubMed&id=pmid:20405364

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.

This entry was posted in General. Bookmark the permalink.

3 Responses to unfortunate SFX behavior with some pmid lookups

  1. dakvid says:

    I have to say that it really bugs me when Ex Libris says that something is part of their design and not a bug. I know there’s a distinction (including degree of effort to fix) between an error in the design and an error in the implementation of the design, but at the end of the day they’re both bugs and a problem for their customers[‘ customers].

    I also find it surprising that they’re not concerned about the inevitable ridicule and appearance of incompetence they garner by proudly declaring that they deliberately designed their systems in this way. (SFX failing the user by requesting the same resource 200 times, Voyager producing duplicate search results, etc)

  2. jrochkind says:

    Agreed. After I brought it up on the EL listserv, they acknowledged it as a bug. As I knew they would eventually. But this was after over a month of back and forth with support. I don’t have time for that, we’re paying pretty signficant money for a support contract, I want to report a bug, have it acknowledged and slated for a future fix, and then I want to not have to think about it again, and eventually it’ll show up in a new version. Note ‘m NOT even demanding it show up in a new version on any particularly speedy timetable, a bug like this isn’t neccesarily of the highest level of urgency — I just want to free my brain to work on the things we’re _not_ paying someone else to do, and not have to think about it, just report it, the end. Frustration with this sort of thing, with how much time and effort it takes to get a vendor to acknowledge a bug, led to me blog posting too, even though I kind of predicted that after even more time and effort rallying the troops on the listserv, eventually they’d agree it was a bug (whether a bug of design or implementation).

  3. dakvid says:

    Unfortunately Voyager support hasn’t been as accommodating at eventually reclassifying enhancements as bugs. Maybe we haven’t pushed as hard as you. But then we shouldn’t have to – as you say considering the money we pay for support…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s