lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harry Yu" <502437...@qq.com>
Subject 回复: Speed up searching in multiple-thread?
Date Mon, 15 Sep 2014 09:41:46 GMT
Hi Toke,‍


Thanks for your reply. I expect the outcome of my application would be 150~200 searches /
per.
Now I'm looking for methods to optimize my application, and want to improve the performance
of the throughout and response time.


17ms / searches is the whole process of search service, include accessing complete data form
db, calling REST service etc.


Regards,


Harry Yu
 




------------------ 原始邮件 ------------------
发件人: "Toke Eskildsen";<te@statsbiblioteket.dk>;
发送时间: 2014年9月15日(星期一) 下午4:47
收件人: "java-user@lucene.apache.org"<java-user@lucene.apache.org>; 

主题: Re: Speed up searching in multiple-thread?



On Mon, 2014-09-15 at 09:10 +0200, Harry Yu wrote:
> I'm developing poi search application using lucene 4.8 . Recently, I
> met a trouble that the performance of IndexSearcher.search is bad in
> multiple-thread environment. According the test results, I found that
> if thread number is 1,  the response time of searching is only 17ms.
> But that would be 400ms when I increased threads to 30. 

With a single thread you have 1000ms/s / 17ms ~= 59 searches/second.
For 30 threads you have 1000ms/s / 400ms * 30 = 75 searches/second

As you have a dual-core machine, the ideal outcome would be 2*59 = 118
searches/second. Accounting for fluctuations in measuring, more GC and a
bit of congestion, it does not seem unreasonable with 75.

(17ms/search seems like quite a long time for such a small index, but
that is independent of the threading issue)


What was the expected outcome of your test?

- Toke Eskildsen, State and University Library, Denmark



---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message