Andrew,
We have a solr implementation that is nearly identical to yours
(includes items from our IR, finding aids, website, etc.) except in
Ruby on Rails. I would say its performance is nearly identical to
yours (on the production server, anyway).
Terry's problems with Rails are somewhat different -- first off, they
chose a method that only can serve one request at a time and, while
there are some applications that this wouldn't be a problem for, a
federated search engine's latency presents a really huge problem in
this regard.
There are quite a few options to get around the problem they ran into
(in fact, they no longer have them), but it was mainly a lack of
research going into production that led to their woes.
-Ross.
On 7/24/07, Andrew Nagy <andrew.nagy_at_villanova.edu> wrote:
> > -----Original Message-----
> > From: Next generation catalogs for libraries
> > [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Erik Hatcher
> > Sent: Monday, July 23, 2007 10:31 PM
> > To: NGC4LIB_at_listserv.nd.edu
> > Subject: Re: [NGC4LIB] Open Source OPAC - VUFind Beta Released
> >
> > (I have to admit that my dream involves a Ruby-fried layer, not PHP,
> > though, but that's just me ;).
>
> "You underestimate the power of the Dark Side. If you will not fight, then you will meet your destiny."
>
> I choose PHP due to it's performance and scalability. I have heard that Ruby has it's issues and is not quite ready for prime time use. I remember at Code4Lib that Terry Reese mentioned something about how he was running into scalability issues with his Ruby implemnetation of their Federated Search engine.
>
> Have you noticed any issues with your flare library?
>
> Andrew
>
Received on Tue Jul 24 2007 - 08:26:27 EDT