Hi Joe,
Jonathan and a few others who have worked with the SFX API more thoroughly than I have may offer you better/different advice here. But, in my (now somewhat dated) experience, the SFX API is much slower than the end-user interface.
For the end-user interface, SFX only needs to show the user the options (= targets). For the API, it also has to generate the final destination URL for each target, and that code also (perhaps inadvertently) records a hit in the usage statistics for each target. So each API call generates a lot more database/processing overhead.
In fact, the performance has never been good enough for us to justify the kind of work you're undertaking here, even though we've wanted to.
--Dave
-------------------------
David Walker
Director, Systemwide Digital Library Services
California State University
562-355-4845
-----Original Message-----
From: Code for Libraries [mailto:CODE4LIB_at_LISTSERV.ND.EDU] On Behalf Of Joe Ferrie
Sent: Tuesday, June 30, 2015 10:05 AM
To: CODE4LIB_at_LISTSERV.ND.EDU
Subject: [CODE4LIB] SFX API scaling
Hi all,
The CDL has been working on a front end for the SFX API (on the Umlaut model), and are wondering whether we can expect SFX performance through the API to have the same profile as performance through the user interface. We're specifically wondering whether the tolerance for concurrency would be the same. We are asking Ex Libris about this, but we thought those with practical experience might have some thoughts, or maybe someone has even done comparative benchmarking. Any thoughts?
Joe Ferrie
Application Programmer
California Digital Library
University of California
Office of the President
415 20th Street, 4th Floor
Oakland, CA 94612-2901
Received on Wed Jul 01 2015 - 12:12:31 EDT