July 23rd, 2008
As you may have noticed, we have not been posting recently to the LibraryFind blog. Basically, we ended up breaking our non-standard blogging solution awhile back, and took way too much time getting WordPress installed and our archived content moved over. However, we are now up and running on WordPress, which should allow us to concentrate on writing on the blog as opposed to maintaining the blog. 
A couple of quick notes - we are getting ready to release the 0.8.5 version of LibraryFind, so check back soon for news of that release. Also, if folks out there are interested in helping us improve our documentation (both technical and user-side), please drop us a note!
Posted by jaf
No comments »
September 18th, 2007
After an amazingly long absence of posting, I’m happy to write that we’ve just released the 0.8.2 version of LibraryFind! There are many improvements in the 0.8 branch. These include:
* Improved out-of-the-box user interface
* re-worked html/css architecture to support easier design customization
* new generic graphic design for out-of-the-box UI
* many, many bugfixes
A current list of closed tickets for the 0.8 branch can be found athttps://trac.library.oregonstate.edu/projects/libraryfind/query?status=closed&milestone=0.8.
And now that 0.8.2 is ready, believe it or not, 0.8.3 is just around the corner. We are setting up testing of the 0.8.3 branch now, and hope to have it out within then next month.
Posted by jaf
No comments »
June 14th, 2007
One of the most frustrating aspects of federating out a search process is the lag time in receiving the results back from the various query targets (especially with, but not limited to, Z39.50 queries). Ideally, at some point in time, there will be an infrastructure service made available which harvests from all of our content providers, and provides us the ability to work with locally (or near-locally) indexed data instead of having to bootstrap via federated querying.
Until that time, however, we need to be pragmatic in order to provide the best user experience possible. Up through LF 0.8 (yes, 0.8 is not quite released yet, but will be very shortly), our approach with the client / server interaction has been to hold open an http request until we can return the full set of search results to the user. Since we are post-processing the results to improve the relevancy, we need to wait until all of the query targets have returned their results before we can provide the user their results. This, in turn, creates open http processes that last way too long - sometimes up to 30 seconds.
So, how to improve on this? In truth, we have no control over the response time of the remote query targets - we cannot make them quicker. Our only approach with these targets is a longer-term effort to work with the providers to allow us better access to their servers or their data (sometimes through an XML gateway instead of Z39.50; optimally through harvesting via OAI-PMH). Since we cannot improve the efficiency of the queries we farm out to remote targets, we need to focus on how to minimize this effect on our users. One method we currently employ to help with this is search result caching - we use a tiered caching system to enable users who happen to enter a search that some other user had previously performed to take advantage of that fact of get their results quite quickly - by caching the results of the first instance of the search, we do not need to go out an query the remote targets again.
Caching works best within user sessions, when a user is more likely to replicate a search precisely. It is less effective across user sessions, because users need to utilize the same precise search terms for it to work. So, caching is no panacea when it comes to reducing the lag, though it does improve the situation.
One of our big changes in the 0.9 branch will be moving away from the persistent http request and instead implementing a ‘constant ping’ approach. Not only will this improve efficiencies from the LF server end (holding open http requests is extremely inefficient, especially with Rails), but it will give us greater flexibility in using the user interface to minimize the impact of slow target responses. We will be able to better inform the user of the status of their search, and we can even provide the user the ability to stop a search mid-stream and look at the results that are currently present. It also opens the door to different UI approaches - for instance, we could more easily devise an A9-style UI, if desired.
None of the above is a silver bullet solution for dealing with the lag - having data available for local or near-local indexing and access is still going to be more effective and efficient than federating a search out across various provider targets, but there currently isn’t the infrastructure in place to support such a scenario. Until then, a combination of bootstrap approaches will continue to improve on the experience LF provides users.
Posted by jaf
No comments »
June 11th, 2007
This is an update to my original post from April on my Rails benchmarking. See this URL for the original.
I have uploaded a more complete PDF of my results from the benchmarks, along with some pretty graphs and stuff.
To recap:
We have 7 different combinations of web server, connector and application server:
Apache 2.2+mod_proxy_balancer+mongrel_cluster
Apache 2.2+CGI/mod_cgi
Lighttpd 1.4+ SCGI+rails_scgi_cluster
Apache 2.0+FastCGI+Rails FCGI
Lighttpd 1.4+mod_proxy_balancer+mongrel_cluster
Lighttpd 1.4+FastCGI+Rails FCGI
Apache 2.2+CGI/mod_cgid
We had 2 separate test rounds:
Test Round 3 consists of executing 500 non-cached queries against LibraryFind. Because the queries are not going to hit the cache, they will take much more time for each individual query to complete, so we are getting an idea of how well this particular combination of webserver/appserver handle concurrent sessions.
Test Round 4 consists of executing 500,000 cached queries against LibraryFind. Because the queries are cached, the back-end remote OAI queries are eliminated, so we are testing just the speed of the actual webserver/appserver/database. Because only the webserver/appserver combinations are changing, we can eliminate the database as a variable. The database is otherwise idle during these tests.
Non-Cached Test Duration: (Test Round 3)
Non-Cached Transaction Rate: (Test Round3)
As you can see from the above graph, of the 7 variations the Apache 2.2/mod_proxy_balancer/mongrel_cluster instance on the far left completed fastest and had the highest number of transactions per second, by nearly 25% over its closest competitor, Apache/FastCGI.
Cached Test Duration: (Test Round 4)
Cached Transaction Rate: (Test Round 4)
Again, with Test Round 4 it is clear that our Apache 2.2/mod_proxy_balancer/mongrel_cluster combination beats out the competition.
People have also asked me for more information on the actual setups of Apache, etc., which I will post soon as well.
Lastly, Terry has added support for memcached to replace the SQL session store that seems to be broken with multiple mongrel instances, so I will try to do some comparison benchmarks to see how much memcached speeds things up.
Posted by rordway
No comments »
April 30th, 2007
BleakHouse is a Rails plugin for finding memory leaks. It tracks ObjectSpace for your entire app, and produces charts of references by controller, by action, and by object class.
Posted by jaf
No comments »
April 25th, 2007
No, this isn’t a Mazda car commercial. Our once and future LF colleague Dan has a very nicepost / screencast / floating-head screencast where he describes how he feels his brain functions when he scans search results (such as results from Google). It’s a very cool, short, and informative video, and I highly recommend it. The part that I really take to is Dan’s example, using fractal geometry, of zooming in and around information.
Dan’s post reminded me of another demo I had seen a few years ago. Jef Raskin, who is credited for much of the original Macintosh UI and specifically features such as the one-button mouse and drag-and-drop, prior to his untimely death in 2005 developed a demo of azooming interface that he was intending to eventually hook into his Archy project. Click on the link to the demo above, and give it a spin (or more aptly, a zoom). Very similar to Dan’s fractal example, no?
Now, let’s think about this in the context of input devices. There are new types of input devices that are starting to become mainstream - the Wimote, for the Nintendo Wii, shows how the input device is a critical component of any user interface. The forthcoming Apple iPhone will use multi-touch technology. If you haven’t seen this video of multi-touch technology, it’s worth looking at.
So, imagine using a multi-touch input device with a zoomable user interface, and apply both to an information discovery and retrieval experience.
Zoom zoom zoom.
Posted by jaf
No comments »
April 19th, 2007
From the Ruby Inside blog comes this reference to a cleverly named Rails plugin called The MOle. From the MOle plugin website:
The MOle allows you to precisely analyze how your customers are interacting with your rails application. Instead of sitting on the console and watching your controller actions and db queries fly by, you can easily leverage the MOle and let it do this work for you by trapping events of interest. This plugin allows you to figure out if your latest application features are a success or a bust. You will be able to trap certain user interactions and record them for your next iterations. This is not yet another page hit or heat map type plugin, within a few steps you will be able to monitor your users interactions LIVE and assess your application usability from the comfort of your own machine…
Check out the video screencast to see it in action.
Posted by jaf
No comments »
April 3rd, 2007
So when we released LF 0.7 I was pretty pleased that we were able to include our own OpenURL resolver. The marriage of metasearch and OpenURL is one of those no-brainer concepts — but in order for it to work really well, I wanted OpenURL resolution directly a part of LF. For OSU and anyone without an OpenURL resolver, this will work great. However, for those that have taken the time to purchase and setup their own tools (like SFX), having OpenURL resolution within the application represented a problem. Soo…
Thanks to Ross Singer, who provided some documentation and the location to the GA Tech. SFX server to test on, I’ve been able to add SFX support into LF. This means that by setting a config value in the environment.rb file, one can configure LF to work with SFX or the Local LF OpenURL repository.
Of course, the next question might be, will we support other openurl resolvers? The answer to that question is easy — sure if they provide an open API for query. SFX makes it easy to retrieve an XML representation of the request results making the service easy to use and parse. Of course, at present, this means that certain vendor tools are off limits. Innovative Interface’s OpenURL software for example, would be out-of-bounds because it lacks such API support. So if you have a vendor that currently doesn’t support an API that returns XML with your OpenURL tool, talk to them. Get them to support it. As soon as they do, give us a holler because support can then be added in just a couple of lines of code.
Posted by jaf
No comments »
April 2nd, 2007
After fighting with concurrency issues with the OSU Libraries implementation of LibraryFind, I decided to do some investigation into the best way to implement the webserver / application server. Ruby suffers from a severe lack of threadiness. That’s my word, don’t steal it!
After scouring the Internet… the whole Internet… I found quite a bit of discussion about how this particular combination was great, but this other combination was even better and thisother combination was horrible. *gasp*
So, being the perfectionist that I am (my wife would disagree), I decided to put them to the test, just like the MythBusters.
I put together a couple of different test cases. I call these “Round 3″ and “Round4″? Where did rounds 1 and 2 go? I don’t know.
Test Round 3 consists of executing 500 non-cached queries against the LibraryFind searcherer, /record/retrieve, using 30 different search terms in quasi-random order. I was hoping to get together a list of 500 different search terms, but my fingers got tired after 30, so I stuck with that. It seemed to do the trick, though! To test concurrency I ran 5 concurrent transactions. The server I was testing on is a dual processor, dual core Opteron (from Sun Microsystems. If I say their name enough, maybe they’ll give me free stuff… ok, this was a Sun Fire X4200!) so much more than 5 concurrent searches (4 really) is just testing how fast your kernel’s SMP or NUMA code is.
Test Round 4 consists of executing 500,000 cached queries against the same searcherer, /record/retrieve, this time using the exact same search term, over and over… and over. Again, I ran 5 concurrent transactions to put the system under as much load as it could reasonably tolerate without getting annoyed with me. Not a true load test, but a good idea of how well the system can retrieve records from cache and spit them back to the user.
The results were somewhat, but not entirely surprising. Of course, using plain CGI worked reasonably well, but was slow. It was so slow, in fact, that I ended up killing the Apache/CGI test after it had completed only about 8600 of its 500,000 transactions because it had already taken longer than Apache/mongrel had for the FULL 500,000… yes, Apache/CGI took more time to complete less than 2% of the test than Apache/mongrel.
Between web servers, Apache 2.2.4 in its worker MPM mode seemed to perform slightly better than Lighttpd 1.4.13 when proxying to mongrel. The opposite was true for Apache 2.0.59/FastCGI (I couldn’t get FastCGI to run against 2.2.4) and Lighttpd 1.4.13/FastCGI. Lighttpd seems to perform better when using FastCGI. After the horrible showing for Apache/CGI I didn’t even try Lighttpd/CGI. I also could not get Apache to work well with scgi_rails.
All in all, I found the combination of Apache 2.2.4 using mod_proxy_balancer to talk to 10 instances of mongrel 1.0.1 (using mongrel_cluster to manage the mongrel instances) to be the fastest, most efficient combination. I also like mongrel_cluster’s ability to manage the independent mongrel instances.
Below are some links to a summary of my findings, and some graphs of the test durations and transaction rates.
Posted by rordway
No comments »
March 30th, 2007
Ah, to be young. I just finished 39 straight hours of coding and after a quick 3 hour nap, ready to tackle the last remaining tickets on the 0.8 trac list. One small niceity that will make it into 0.8 is a diagnostic tool that will allow you to test a configured database before using it in real-time in LibraryFind. This will let you make sure that LF understands your OAI server, can read your OpenSearch resource or can talk to your Z39.50 client. While the 0.8 release won’t have a lot of updates in the admin functionality (that’s on the 0.9 cycle) — there will be some improvements that I think will make life a little easier for folks. Of course one of those improvements is the yet to be written ruby component for loading coverage data into LF. We have a PHP script that currently performs the feat, so I guess I ought to get coding again.
Oh, and before I forget. I’d like to set LF up so that you can use SFX as your OpenURL resolver — however, we are not an SFX shop. I understand that SFX provides a method for querying and getting data back in XML. If someone with SFX (hey Ross) has some documentation or some sample urls so I can see what the response format looks like — I’ll make sure 0.8 supports it.
Posted by reeset
No comments »
