lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Gardner (JIRA)" <>
Subject [jira] Updated: (LUCENE-1337) [PATCH] improve searching under high concurrancy
Date Wed, 16 Jul 2008 17:32:31 GMT


Brian Gardner updated LUCENE-1337:

    Attachment: lucene.patch

This patch applies to version 2.3.1

> [PATCH] improve searching under high concurrancy
> ------------------------------------------------
>                 Key: LUCENE-1337
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>    Affects Versions: 2.3.1
>         Environment: Linux
>            Reporter: Brian Gardner
>            Priority: Minor
>         Attachments: lucene.patch
> I was trying to load test my web server and kept running into a condition were the web
server would become unresponsive even though the load was below one.  Turns out Lucene has
synchronization blocks around reading the index.  It appears this was only necassary to synchronize
access to a descriptor which contains a RandomAccessFile and information about the state of
this file.  My solution was to use a pool of descriptors so that they could be reused on subsequent
reads.  During periods of low contention only one or a few Descriptors will be created, but
under heavy loads many Descriptors can be created to avoid synchronization.  After creating
and applying my patch, I was able to triple my searching throughput and fully utilize the
resources, the CPU's becoming the new bottleneck.   My patch modifies FSDirectory directly,
but I'm not entirely sure that's the proper implementation.  I'd like to help resolve this
synchronization issue for other lucene users, so please let me know how I can help.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message