RE: Slowness on Java 11 with Lucene 6

2019-07-29 Thread Uwe Schindler
Hi,

We did not notice any slowdown with queries based on Java version, if the 
configuration is identical.
But Java 11 uses G1GC as default garbage collector, in contrast to Java 8 which 
uses ParallelGC as garbage collector. G1GC has no longer pause times anymore 
(so you application won't halt anymore for longer time), but in contrast it 
slows down the throughput.

If you use Solr or Elasticsearch, those applications configure the garbage 
collector for use with search, but if you just run your application with Java 8 
and default command line parameters, slowdowns due to different defaults may be 
possible.

I'd suggest to make sure that the garbage collector is configured in a defined 
way and then compare again. We also don't know on the mailing list what you 
have done (is it pure Lucene, is it Solr, or is it Elasticsearch?) and how your 
JVM is configured. So assumed the worst case (default settings with pure Lucene 
application).

Uwe

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: GASPARD-EXT Joel 
> Sent: Monday, July 29, 2019 5:17 PM
> To: java-user@lucene.apache.org
> Subject: Slowness on Java 11 with Lucene 6
> 
> Hello,
> 
> We have noticed slower response times on search with Lucene 6 when
> upgrading to Java 11.
> 
> We use the version 6.6.5 of Lucene. Our servers are on Windows, with SSD
> devices. Our index contains several millions of documents.
> When upgrading from Java 8 to Java 11, we have noticed slower response
> times in query searches : sometimes 30% slower, sometimes twice as slow,
> depending on the server capacity.
> 
> We measure response times with 20 queries.
> We have made our tests with different JDK providers. We have noticed the
> same deviation.
> 
> Have you encountered this problem ?
> 
> Thanks
> 
> 
> 
> 
> 
> Ce message et toutes les pi?ces jointes qu'il contient sont uniquement
> destin?s aux personnes auxquelles ils sont adress?s et sont strictement
> confidentiels. A moins qu'il en ait ?t? explicitement convenu autrement, son
> contenu ne refl?te que la pens?e personnelle de son auteur et ne saurait
> donc repr?senter la vision officielle de l'Entreprise. Si vous avez re?u ce
> message par erreur, nous vous remercions de bien vouloir en informer
> l'exp?diteur imm?diatement par retour d'email et supprimer d?finitivement
> le message de vos r?pertoires. Toute utilisation de ce message non conforme
> ? sa destination, toute diffusion ou toute publication, totale ou partielle, 
> est
> interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer
> l'int?grit? de ce message, l'Entreprise d?cline toute responsabilit? au titre 
> de
> ce message, dans l'hypoth?se o? il aurait ?t? modifi?.
> 
> 
> This message including any attachments is confidential and intended solely
> for the addressees. Unless explicitly mentioned, its content reflects only the
> personal thoughts of the author, and therefore cannot represent the official
> view of the Company. If received by error, please inform immediately the
> sender by return e-mail and delete definitely the message from any and all
> directories. Any use, dissemination or disclosure not in conformity with the
> intended purposes is strictly prohibited. The integrity of messages via
> Internet cannot be guaranteed and the Company accepts no liability for any
> changes which may occur.


-
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org



Slowness on Java 11 with Lucene 6

2019-07-29 Thread GASPARD-EXT Joel
Hello,

We have noticed slower response times on search with Lucene 6 when upgrading to 
Java 11.

We use the version 6.6.5 of Lucene. Our servers are on Windows, with SSD 
devices. Our index contains several millions of documents.
When upgrading from Java 8 to Java 11, we have noticed slower response times in 
query searches : sometimes 30% slower, sometimes twice as slow, depending on 
the server capacity.

We measure response times with 20 queries.
We have made our tests with different JDK providers. We have noticed the same 
deviation.

Have you encountered this problem ?

Thanks





Ce message et toutes les pi?ces jointes qu'il contient sont uniquement destin?s 
aux personnes auxquelles ils sont adress?s et sont strictement confidentiels. A 
moins qu'il en ait ?t? explicitement convenu autrement, son contenu ne refl?te 
que la pens?e personnelle de son auteur et ne saurait donc repr?senter la 
vision officielle de l'Entreprise. Si vous avez re?u ce message par erreur, 
nous vous remercions de bien vouloir en informer l'exp?diteur imm?diatement par 
retour d'email et supprimer d?finitivement le message de vos r?pertoires. Toute 
utilisation de ce message non conforme ? sa destination, toute diffusion ou 
toute publication, totale ou partielle, est interdite, sauf autorisation 
expresse. L'internet ne permettant pas d'assurer l'int?grit? de ce message, 
l'Entreprise d?cline toute responsabilit? au titre de ce message, dans 
l'hypoth?se o? il aurait ?t? modifi?.


This message including any attachments is confidential and intended solely for 
the addressees. Unless explicitly mentioned, its content reflects only the 
personal thoughts of the author, and therefore cannot represent the official 
view of the Company. If received by error, please inform immediately the sender 
by return e-mail and delete definitely the message from any and all 
directories. Any use, dissemination or disclosure not in conformity with the 
intended purposes is strictly prohibited. The integrity of messages via 
Internet cannot be guaranteed and the Company accepts no liability for any 
changes which may occur.


Is QueryRescoring API faster than a new search

2019-07-29 Thread Ameer Albahem
Hi all,

Given a new query (finalQuery), I am trying to rescore the top 1000
documents that match an original query using the QueryRescore API.  To my
surprise, if we run the new query using a new search such as:

searcher.search(finalQuery,1000)

then it is faster than using the rescoring API:

QueryRescorer.rescore(searcher,topDocs,finalQuery,1,1000)


Is this normal or expected? if yes, then how can we make the rescoring
process faster than a new search?

Regards
Ameer