Zender

Hallo Leute,

ich muss eine große Datenmenge mittels Zend Lucene indexieren.
Es handelt sich um eine Größenordnung von mehreren 10.000 Dokumenten die regelmäßig zum Index hinzugefügt werden müssen.
Ich habe allerdings Probleme, den benötigten Speed zu erreichen.

Meine Dokumente sind alle gleich aufgebaut und enthalten 5 Keyword-, 4 Text, und 2 UnIndexed Felder die jeweils mit ein paar kleinen (<100Byte), größtenteils Strings, Werten gefüllt sind.

Diese Dokumente erstelle ich und speichere sie in ein Array.
Zu einem bestimmten Zeitpunkt möchte ich sie alle dem Index hinzufügen. Dieser Vorgang dauert 0.02s pro Dokument, also nur 50 Docs/s, was definitiv zu langsam ist und auch eigentlich nicht angehen kann. Am Server kann es nicht liegen, es handelt sich um einen schnellen 64bit Rootserver mit 4GB RAM, wobei allein PHP 1GB zugeteilt sind.

Ob der Index noch komplett leer ist, optimiert, oder nicht optimiert ist, ich erhalte nahezu immer diesen langsamen Wert.
Die Optimierungseinstellungen MaxBufferedDocs, MaxMergeDocs, MergeFactor sind alle auf ihren Standardwerten, da Veränderungen an diesen höchstens zur Verschlimmerung der Werte geführt haben.

Hat jemand eine Idee, wo hier Flaschenhälse vorhanden sein können?

Vielen Dank für jede Antwort schon einmal an dieser Stelle, Zender

PS:
Das englischsprachige Zend Forum ist leider total unfrequentiert, sonst hätte ich direkt dort gepostet. Ich hoffe, hier gibt es jemanden, der mit Zend Lucene Search vertraut ist.

Mister Ad

robo47

Hast du die Möglichkeit mal mittels Xdebug oder einem anderen Debugger (notfalls auch in einer lokalen Testumgebung) deinen Code mal zu testen, mit aktiviertem Profiler, danach kannst du mit WincacheGrind (Windows) / KCacheGrind (Linux), die erstellten Profiles auswerten.

Ausserdem solltest du mal schauen wie die CPU-Last während dem ganzen ist, wenn es eine Dual-Core oder Quadcore-CPU ist oder auch ein System mit mehreren CPUs, hast du das Problem, dass 1 PHP-Prozess maximal einen Core nutzen kann, daher solltest du schauen, dass du mehrere Instanzen parallel laufen lässt um die Performance auch auszunutzen.

Falls du das ganze noch über den Browser ( mod_php ) laufen hast, solltest du schauen das script direkt via shell über den php-(cgi)-interpreter zu starten.

Sollte Zend_Lucene irgendwo im Dateisystem einen Cache oder ähnliches nutzen, wäre es eventuell noch möglich ein bißchen RAM für ein RAM-Drive zu reservieren und diese temp-files dort auszulagern.

Man muss auch sagen, dass laut deiner Rechnung das ganze ja "nur" ~ 3 1/2 Minuten dauert, das empfinde ich jetzt nicht unbedingt als sonderlich lange.

Was ist übrigends gemeint dass du 1GB vom RAM für php hast ?
Ist das die Einstellung für max_memory ? Darf APC (oder ein anderer Bytecode-Cache ) so viel RAM nutzen ? Memcache für Daten ? ... ?

Mehr fällt mir jetzt ohne etwas mehr über das wie und das aussenrum zu erfahren nicht mehr mehr ein.

btw gibt es auch ein deutsches Zend Framework Forum: Zend Framework Forum - Powered by vBulletin

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Zender

Hallo robo 47,

danke erst einmal für deine umfassende Antwort.

Zum Profiling:
Wenn ich einen Profiler zuschalte, wird die Datenmenge des Logfiles schon bei wenigen Durchläufe meines Scripts (50.000) so groß, dass ich den Profile-Vorgang abbrechen muss. Bei 1000 Durchläufen hatte ich eine 100MB-Logdatei, dort konnte ich allerdings auch nur erkennen, dass die addDocument-Funktion von Lucene den Großteil der Zeit ausmacht...

Zum RAM:
Ja, max_memory steht auf 1024MB, weitere Einstellungen habe ich nicht verändert. Ist das nötig?

Zur Ausführungsart:
Beim Aufruf über den cli-Interpreter läuft das Script minimal schneller, allerdings ist der Unterschied im Vergleich zur Dauer der Luceneoperationen vernachlässigbar.

Allgemein zur Geschwindigkeit:
Die Indexierungsgeschwindigkeit ist nach längeren Tests die ich gerade durchgeführt habe noch langsamer, etwa bei 10 Dokumenten / s.
Afaik brauche ich eine viel höhere Geschwindigkeit, es kann doch nicht sein, dass das so langsam geht
Mir ist weiterhin folgendes aufgefallen:
Ich habe ein Unique-ID-String String Feld in jedem Document. Falls ich Documents update und nicht neu erstelle, dann lösche ich das alte Dokument mit dieser ID und füge ein neues ein.
Der Löschvorgang nimmt, falls die Indizierung nur aus Updates besteht, die Hälfte der Zeit ein.

Meine Löschfunktion:

protected function Remove($guid)
{
$term = new Zend_Search_Lucene_Index_Term($guid, 'guid');
$query = new Zend_Search_Lucene_Search_Query_Term($term);

$hits = $this->Find($query);
if (count($hits) == 1)
{
$this->index->delete($hits[0]->id);
// Log::Write("Remove: " . $guid);
}
}

Ich wäre dir sehr verbunden, falls du einen Hinweis darauf hättest, warum ich diese Probleme habe. Wenn du weitere Informationen brauchst, ich liefere sie gerne.

Gruß, Zender

robo47

Naja die Frage ist ob ein einzelner Prozess überhaupt so viel braucht, der Speicher ist ja auch nicht wirklich reserviert, es ist ja nur die Angabe wie viel RAM JEDER einzelne Prozess nutzen darf. Um den Wirklichen Verbrauch des Scriptes einzuschätzen kannst du dir ja mal am ende des scripts via PHP: memory_get_peak_usage - Manual dir den maximalen Verbrauch des Scriptes in ne Log ausgeben lassen.

Was einen allgemeinen Geschwindigkeitsvorteil für alle PHP-Scripte bringt, ist der Einsatz eines BytecodeCaches wie APC, eAccelerator, PHP-Accelerator oder Zend Optimizer, denen weißt man eine feste Menge RAM zu um darin den Bytecode der Scripte zu cachen und wahlweise können dort auch Variablen von php-scripten gespeichert werden (prozess und script übergreifend).

Unter Umständen kann man durch das kompilieren von php weitere Geschwindkeitsvorteile bekommen indem man sich ein php kompiliert das nur das absolute Minimum an Extensions mitkompiliert die gebraucht werden, kann auch nochmal ein bißchen was bringen.


Ich hab gerade mal noch das Zend Manual zu Zend_Lucene überflogen, da dieser Index ja komplett auf der Festplatte gespeichert wird, hat die Festplatte auch einen großen Einfluss auf die Performance. Hier kann man verschiedenes machen, z.b. den Index auf einer extra Festplatte auslagern, die weniger ausgelastet ist oder eben, die wohl schnellste Lösung, ihn auf ein RAM-Drive auslagern. Das ganze ist aber auch abhängig von der Größe des Index.
Desweiteren bei einem Server-Ausfall bzw. Reboot ist der Index dann futsch und muss neu erstellt werden, ausser man erstellt nach jedem überarbeiten des Index ein Backup vom RAM-Drive auf die Festplatte und bastelt sich ein Script das beim Booten nach dem erstellen des RAM-Drives, das Backup auf das RAM-Drive kopiert.

Ich kann halt absolut nicht abschätzen wie der Server ansonsten ausgelastet ist (nicht nur CPU, sondern auch IO-Auslastung der Festplatte, etc), also wo eventuelle Performance-Bottlenecks noch auftreten. Denke da wirst du noch etwas rumtesten müssen, über die Profiles sollten eventuell auch einen Hinweis darauf geben wie lange die Schreib-Operationen dauern und das ganze dann gegebenenfalls eben mal mit ner weiteren Festplatte für den Index oder aber einem RAM-Drive austesten.

Ein paar weitere Fragen und Anhaltspunkte vielleicht noch:

Ist denn die CPU während dem Indizieren durch den Prozess voll ausgelastet ? Wenn nicht wäre das eben ein eventuelles Indiz dafür, dass das Bottleneck zumindest nicht die CPU ist.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework

Zender

Ich ermittele bereits den höchsten genutzen Ram-Wert während der Indizierung, dieser liegt bei ca 800MB, da ich eben viele Dinge auf einmal cache die dann nach und nach (teilweise) indiziert werden.
Der Server ist momentan nur für dieses Projekt reserviert, dort läuft nichts außer einer Apache/MySQL Instanz.

Der Flaschenhals muss eigentlich bei der CPU/RAM liegen, und das deutet meiner Meinung nach darauf hin, dass irgendetwas bei Lucene falschläuft.
Der Index ist danach grade mal höchstens ein paar MB groß, nichts also, womit die Festplatte in irgend einer Weise Probleme haben sollte.

Gibt es irgendwelche Einstellungen in Lucene die unbedingt getätigt werden müssen, oder angepasst werden müssen? Kann evtl ein verwendeter Zeichensatz etc dafür sorgen, dass Lucene so unglaublich langsam arbeitet? Falsche Codierung oder so?

Zender

Ich habe gerade noch einmal genau beobachtet:
Während dem Hinzufügen von Dokumenten nimmt sich der Prozess die mit abstand höchste CPU-Auslastung. Es muss sich also um irgendetwas Lucene-Internes handeln, oder aber eine falsche Konfigurationseinstellung.

Ich denke, normalerweise sollte das ganze doch mindestens um den Faktor 20 (wenn nicht noch wesentlich mehr) schneller laufen

Zender

Ich habe jetzt einmal ein kleines Testscript erstellt, mit dem ich nachvollziehen möchte, warum die Lucene Komponente so langsam arbeitet:

Das Script soll das Hinzufügen von 5000 Dokumenten zu einem leeren Lucene Index simulieren. Der Index ist danach nichtmal einen Megabyte groß, die Laufzeit beträgt bei mir trotzdem stattliche 45s, wovon nahezu die gesamte Zeit allein auf das Senden der Dokumente entfällt. Warum braucht Lucene hier so lange, bzw wie ist es möglich, dass ich möglichst schnell tausende Dokumente zum Index hinzufüge?

Zender

Ich habe, um das hinzuzufügen, auch mit den Werten MaxBufferedDocs, MaxMergeDocs und MergeFactor herumgespielt, diese bewirken jedoch keinerlei Änderung an der Laufzeit...

robo47

Soweit ich mir den Code von Zend_Search_Lucene angeschaut habe, passiert ja auch die ganze Analyse in der methode addDocument().

Du kannst ja mal nen profiler-dump von so nem ablauf uppen, dann schau ich es mir den mal an.

__________________
robo47.net - Blog, Codeschnipsel und mehr
| Caching-Klassen und Opcode Caches in php | Robo47 Components - PHP Library extending Zend Framework