 |
 |
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:[log in to unmask]] On Behalf Of Joe Ferrie Sent: Tuesday, June 30, 2015 10:05 AM To: [log in to unmask] 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