Discussion:
WildcardQuery-Erzeugung in neueren Lucene-Versionen langsamer
(zu alt für eine Antwort)
Christoph Schneegans
2016-03-15 17:00:59 UTC
Permalink
Hallo allerseits!

Gegeben sei folgender Code:

@Test
public void performance()
throws Exception
{
for (int i = 0; i < 100_000; i++)
{
new org.apache.lucene.search.WildcardQuery(
new org.apache.lucene.index.Term("foo", "foo*"));
}
}

Ich stelle hier erhebliche Unterschiede in der Laufzeit fest:

• Mit Lucene 3.4.0 läuft dieser Code in 0,026 s durch.
• Mit Lucene 4.10.4 benötigt er schon 0,549 s.
• Und mit Lucene 5.5.0 benötigt er gar 2,601 s.

Ich habe bei meinen Tests auch nicht den Eindruck, daß Lucene 4.x und
5.x die investierte Zeit später, also bei der /Ausführung/ der Query,
wieder reinholen.

Die WildcardQuery wurde ja in 4.x als AutomatonQuery re-implementiert.
http://de.slideshare.net/otisg/finite-state-queries-in-lucene spricht
nun (auf Slide 9) von "improved performance", ganz im Gegensatz zu
meinen Erfahrungen.

Übersehe ich irgendwas Offensichtliches?
--
<http://schneegans.de/computer/safer/> · SAFER mit Windows
Marcel Mueller
2016-03-15 21:09:31 UTC
Permalink
Post by Christoph Schneegans
@Test
public void performance()
throws Exception
{
for (int i = 0; i < 100_000; i++)
{
new org.apache.lucene.search.WildcardQuery(
new org.apache.lucene.index.Term("foo", "foo*"));
}
}
• Mit Lucene 3.4.0 läuft dieser Code in 0,026 s durch.
• Mit Lucene 4.10.4 benötigt er schon 0,549 s.
• Und mit Lucene 5.5.0 benötigt er gar 2,601 s.
Die haben halt die Nutzung der Systemressourcen optimiert. Die neuen
Versionen nutzen die Systemressourcen wesentlich effektiver aus als die
alten. ;-)
Post by Christoph Schneegans
Ich habe bei meinen Tests auch nicht den Eindruck, daß Lucene 4.x und
5.x die investierte Zeit später, also bei der /Ausführung/ der Query,
wieder reinholen.
Das wird halt auch davon abhängen, über welche Datenmenge er nachher
drüber rutschen muss.

Einen Overhead von 26µs für eine Volltext-Suchanfrage finde ich jetzt
nicht in irgendeiner Weise so beeindruckend, als dass sich darüber
irgendeine Diskussion lohnt.
Post by Christoph Schneegans
Übersehe ich irgendwas Offensichtliches?
Was ist den das eigentliche Problem? Geht es den Kunden zu langsam? Hat
der Server nicht mehr genug CPU-Kerne, um die Anfragen zu bearbeiten?
Irgendetwas anderes?

Und hast Du mal getestet, ob nicht das Initialisieren der (größer
gewordenen) Bibliothek das ist, was langsamer geworden ist? Also mal
eine Anfrage vorher im Setup machen, was nicht zur Zeit dazu zählt.


Marcel
Christoph Schneegans
2016-03-16 11:29:47 UTC
Permalink
Post by Marcel Mueller
Post by Christoph Schneegans
• Mit Lucene 3.4.0 läuft dieser Code in 0,026 s durch.
• Mit Lucene 4.10.4 benötigt er schon 0,549 s.
• Und mit Lucene 5.5.0 benötigt er gar 2,601 s.
Was ist den das eigentliche Problem?
Wir haben einige automatisierte Performance-Prüfungen, die nach dem
Wechsel der Lucene-Version erhebliche Verschlechterungen attestierten.
Ich habe aber zunehmend den Eindruck, daß diese Prüfungen reale
Suchanfragen nicht besonders gut abbilden. Wahrscheinlich renne ich
gerade einem Phantom hinterher...

Bestimmte Anfragen, die per
org.apache.lucene.index.AtomicReader#terms(String) direkt auf Terme
eines Feldes zugreifen, laufen nun sogar erheblich schneller.
Post by Marcel Mueller
Und hast Du mal getestet, ob nicht das Initialisieren der (größer
gewordenen) Bibliothek das ist, was langsamer geworden ist? Also mal
eine Anfrage vorher im Setup machen, was nicht zur Zeit dazu zählt.
Okay. Auch mit Warmlaufen ändern sich die Meßergebnisse nicht wesentlich.

Das soll mir aber vorerst genügen. Danke für deine Antwort!
--
<http://schneegans.de/lv/> · Validator für BCP 47
Lesen Sie weiter auf narkive:
Loading...