This article offers some design considerations aimed at improving the speed of an application using the Metalib X-Server.
Performance
Web services are all the rage these days, but they sometimes come at the expense of bandwidth and performance. XML-based messages are bulky; firewalls and network latency can slow down transmissions, and XML programming objects and processors can quickly eat-up computer resources.
The benefits of a web services approach can far outweigh these performance costs, especially in the case of Metalib, but design is critical. Here are some recommendations from the field:
1. Build locally whenever possible
One of the great benefits of the Metalib X-Server is that you don’t have to use it. That is, you can utilize only those functions that you need, and locally develop other functions to take advantage of improved flexibility or speed.
Login
The PDS authentication system can be painfully slow. It’s not unusual for users at Cal State, for example, to experience 30-second-plus wait times during login!
The X-Server includes functions for authenticating a user via PDS, but our Xerxes system can directly authenticate users against our local Active Directory server in sub-second time.
Categories and database selection screens
The X-Server includes several functions for retrieving information about subject categories and databases in the Metalib Knowledgebase. However, if you store all of this information in a local database, you can retrieve it much faster.
We keep all of our information about our subscription databases and subject categories in a couple of simple Oracle tables. All you need is a column to hold the Metalib ID number for each database so you can feed that to the X-Server in a metasearch query.
Save and export options
Ex Libris has no immediate plans to include X-Server functions for saving records to a user’s e-shelf, so if you wish to give your users the ability to save and export records, you really have no choice but to build those options locally. Xerxes saves user-selected records to a local Oracle database, again providing significant performance advantages when retrieving those records later in a user’s “saved records” page.
2. Use the URL parameters
When I switched from using the XML POST method to using the URL parameters, I saw a noticeable improvement in response time.
This makes sense. It takes web services more time to processes XML than to grab URL parameters, and you’ll see significant performance improvements in other popular web services like Amazon when using REST versus SOAP .
3. Only ask for what you need
Most of the initial communication between your application and the X-Server includes small messages regarding the status of your metasearch request. When you start pulling back search results, however, the responses get very large, very fast.
By default, Metalib sends back the entire record for each result. That’s not a problem when you’re requesting one record at a time. But when you initially present users with the results of their search, you’ll likely be showing them 10 records at a time.
The X-Server provides a very useful parameter here called view , which you can set to full , brief , or customize . Setting view to customize allows you to specify additional field parameters, instructing the X-Server to output those fields (and only those fields) in the response.
X?op=present_request&format=marc&view=customize
&field=020##&field=100##&field=245##
By requesting only those fields that you plan to display (or use in display logic), you can keep the response size down, allowing the X-Server to deliver it across the network faster.
4. Save OpenURL parsing until you need it
One of the fields you can ask for in a customize view is OPURL , which instructs the X-Server to return an OpenURL Context Object with the record. Parsing out the information necessary to create the Context Object is resource intensive on Metalib’s end, and will significantly slow down response times in your 10-record results page.
Xerxes doesn’t ask Metalib for an OpenURL when pulling 10 records at a time. Instead, it displays an SFX button that simply points to a redirect page with the record’s identifiers in the querystring.
<a href=”metasearch?action=sfx&resultSet=004120&startRecord=000002″>
Only once the user clicks on the link does Xerxes turn back to Metalib and ask for an OpenURL, in turn redirecting to our SFX menu.
5. Keep transformations as simple as possible
One of the great benefits I see in the X-Server is the ability to customize results based on the source database. We can, for example, provide links to the native full-text, show the format of each record, and other unique fields by looking at where that record came from, and processing it accordingly.
The more conditional logic you put into an XSLT transformation or an XML programming object, however, the longer it takes to display the results. We’re talking milliseconds here, so customization of the results based on the source database is certainly possible. You just need to strike a good balance.
6. Cap metasearch times
Although some vendors have greatly beefed-up their Z39.50 and XML servers in recent years to help facilitate metasearching, other vendors utilize slower servers.
With Xerxes, we’ve set a local limit on the number of times it will check the status of a metasearch. If it hits that limit — 35 seconds — and not all databases are done searching, it merges what is available, and moves on.
7. Cache results
If necessary, an X-Server application can pull down search results asynchronously and cache the XML locally. For example, after your application displays the first page of results for a search, it can immediately kick-off a request to Metalib for the next page of results, storing that on disk or in a database until the user hits the next button, at which point it would pull it up locally.
We haven’t had a need to go this route yet, but caching and asynchronous pulling of records are useful methods to keep in your toolset for large web services projects.
8. Design a usable interface
Ultimately, speed is a matter of perception.
Jared Spool , the popular web usability expert, has done a lot of research in this area. He reports that user perceptions of a website’s speed have little to do with how many seconds it takes for pages to load . Rather, if users find your website or application easy to navigate and use, they perceive it to be fast. If your application is difficult to use, however, they begin to complain about speed.
Devoting the lion’s share of your time and resources to designing a usable interface that provides clear labels and simple navigation, and gives users enough information to make decisions easily, can do more to improve your application than any of the technical recommendations above.
The ultimate speed concern here, then, is not page load times specifically, but rather how quickly a user can get into your application and find the full-text of the books and articles they are looking for. A lot can be said on this point, but I’ll leave that for another article.
