You can always read the current index into a RAMdir, but I really wonder if that will make much of a difference, as your op system should be taking care of this kind of thing for you.
How big is your index? What kind of performance are you seeing? What else is running on that box? I'd do some profiling to see where things are actually slow. In particular, think about logging how long each query takes to complete, just the Lucene part. I've seen similar situations where the actual time was being taken *outside* of lucene itself by XML manipulations, for instance. Also, are you iterating over a Hits object for more than the top 100 entries? That would be very inefficient. Are you using a collector and calling IndexReader.doc() inside the loop? I'd *very* strongly recommend that you pinpoint where the time is actually being spent before jumping to the conclusion that using a RAMdir would fix your problem. I can't tell you how many times I've been *sure* I knew where the bottleneck was only to find out that it's someplace completely different. You simply cannot reliably optimize performance without really understanding where the time is being spent. Trust me on this one <G>... Some simple timings with System.currentTimeMilliseconds() will tell you a lot. Best Erick On 7/2/07, Cathy Murphy <[EMAIL PROTECTED]> wrote:
Is there a way to store lucene index in memcache. During high traffic search becomes very slow. :( -- Cathy www.nachofoto.com
