On 18.11.2007, at 18:51, Jens Kraemer wrote:
> Trac is online again for days, and Ferret even got a new logo :-) I
> wouldn't call it abandoned, it's just stabilizing.
Yes, I noticed that. I should have checked before posting. However, a
project site that is frequently down for extended periods of time is
not exactly building up trust :)
> 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.
My apologies for implying that AAF is part of the problem. It
certainly isn't. I made the mistake to mix up my concerns about Ferret
with comments on AAF. What I actually meant to say, is that AAF is one
viable way to deal with some of Ferret's shortcomings.
The fact that in the Rails community AAF is almost synonymous with
Ferret speaks for your plugin and I'm not in a position to question
that.
> 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.
Again, I wasn't to blame AAF here.
To be more precise: Ferret is pretty damn fast. The problem is its
extremely sensitive API which exposes problems from the C
implementation to the Ruby developer. I don't know of any way to catch
a segfault in Ruby, and even if I did, there's little I can do about
it from Rubyland.
Without transactional index updates, such behavior is intolerable,
unless you can afford to rebuild your index several times a day. This
leaves us to build another Ruby API on top of Ferret's in order to
compensate for these imperfections.
I wrote a custom solution with a focus on reliability. But with all
the infrastructure built around Ferret (DRb server, transactions,
queuing), the overall indexing performance wasn't that great anymore:
Remote indexing with 10 concurrent clients was 8-9 times slower than
local indexing.
Maybe AAF is faster, but since the implementations are different,
there's no point in comparing them directly.
Andy
_______________________________________________
Ferret-talk mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ferret-talk
