[hibernate-dev] Search: some changes to new perf tests

Sanne Grinovero sanne.grinovero at gmail.com
Mon Jun 2 14:15:33 EDT 2008


Hi Emmanuel,
I've done some changes to your recent new test about Search performance,
I first introduced a common "start signal" to all threads to ensure I
was testing
the concurrency, but wen I did and after you fixed the latest bug (HSEARCH-204)
it appeared that Search was performing approximately twice as fast as
raw Lucene, quite a suspect behaviour ;-)
So I found that the Lucene test was iterating
on results from 0 to <=100, not 0 to <100, so actually fetching more
than 100 results (101). As Lucene collects the data in it's Hits
at batches of 100 elements, this introduced a x2 overhead for the
pure Lucene tests.
(we could exploit this for .setMaxResults() )

Besides that I introduced some other minor changes:

A)Synchronization to read the timings (it doesn't interfere wit timings).

B)Use of an Executor

C)A start signal (a simple CountDownLatch)

D)I had to disable in-thread logging and enable
multiple iterations per-thread as it completed too fast
to provide a reliable reading of numbers;
It's still quite variable (gc?), but gives an idea to compare
Lucene to Search.

approval to commit?

Sanne



More information about the hibernate-dev mailing list