Hi! On Sun, Nov 18, 2007 at 10:24:34AM -0500, [EMAIL PROTECTED] wrote: > Andy, > > You asked about other full text indexes for Ruby/Rails. I am using both > AAF/Ferret and Sphinx in my app. > > I haven't had any problems with Ferret or acts_as_ferret so far. I am > using the DRb server and it is being hit with 200-250,000 requests a day > from dozens of clients (Mongrel instances). My index isn't huge - it is > about 600 MB.
ah, glad to see somebody where everything just works standing up and tell the world :-) On Sun, 18 Nov 2007, Andreas Korth wrote: [..] > > > > What worries me most is the fact that Ferret is effectively an > > abandoned project. The original author, who is the sole owner of the > > code, hasn't been posting to this list for about six months. He hasn't > > introduced any improvements in about the same period of time and many > > bugs still remain unfixed. New bugs can't be submitted (let alone > > patches) because the project Trac is offline. Trac is online again for days, and Ferret even got a new logo :-) I wouldn't call it abandoned, it's just stabilizing. > > There is no other component in my applications which behaves as badly > > as Ferret. If you don't treat it _very_ carefully it will throw > > segfaults as if this was an established way of indicating an error > > condition. > > > > The ActsAsFerret plugin _does_ treat ferret quite carefully and it's > > the only reason why many people are able to use Ferret at all. > > However, AAF is one approach and for some applications it might not be > > the right one. Especially if you want to put multiple models in one > > index - it's possible, but not really a flexible solution. Well, even if aaf doesn't fit your needs, you might at least have a look at it if you want to know how to treat your Ferret well :-) I admit it isn't always an easy library to deal with, but with a proper set of unit tests it's entirely possible and no headache at all. Imho. > > The most sensitive point of Ferret is concurrency and many people > > actually use Ferret in distributed environments (which is usually a > > Rails app that scales across several machines). AAF introduces a DRb > > server to work around this problem, but with many concurrent read/ > > write requests, performance quickly degrades. AAf's DRb server can handle some serious load as it is now, but for sure there's much room for improvement. However I didn't receive many complaints from people actually *having* this problem in real life applications yet. Most of the time this is brought up as some kind of 'what if' problem. Somebody did a speed comparison of Solr and aaf/Drb a while back, where aaf was at least as fast as Solr was, with it's admittedly naive DRb server. I don't say this was a representative benchmark or anything, but it's the only numbers I know of... So please from now on, anybody feeling to blame aaf's DRb as slow, *please* show us some numbers and the test process which led to these numbers. Ideally you'd also show us the numbers of any solution you've found to be faster solving the same problem. Thanks. > > With the advent of JRuby, a myriad of Java-based solutions is now > > accessible to Ruby developers, including many full-text indices. There > > are very mature solutions readily available for production use and > > many next-generation search engines currently in development. For sure. I'm excited by these possiblities as well. Cheers, Jens -- Jens Krämer http://www.jkraemer.net/ - Blog http://www.omdb.org/ - The new free film database _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
