Volltextcache liest nur Dateien bis 16 MB

[j3nsch]

Im der Klasse Opus_Search_FulltextFileCache gibt es eine feste Begrenzung auf 16 MB. Es ist unklar, ob das sinnvoll ist, weil es dazu führt, das die Originaldateien immer wieder zu Solr für eine Extraktion gesendet werden. Je größer die Datei desto wichtiger der Cache.

Eine solche Begrenzung macht nur im Zusammenhang mit einer Begrenzung für die Volltextextraktion Sinn. Wenn die Datei zu groß für den Cache ist, dann ist sie zu groß für die Extraktion. Oder andersherum wenn die Extraktion möglich ist, sollte das Speichern im Cache möglich sein, da es darum geht die teuren Extraktionskosten zu reduzieren.

Leider steht in der Klasse nicht warum die Begrenzung eingeführt wurde. Die Situation muss mindestens geklärt und dokumentiert werden.

Gibt es Dateien, die zu groß für die Volltextextraktion sind? Diese Frage ist unabhängig von den aktuellen Problemen mit verhältnismäßig kleinen Dateien.

Intern: https://tickets.zib.de/jira/browse/OPUSVIER-3688

[j3nsch]

Große Testdateien sollten nicht ins Git-Repository aufgenommen werden. Daher sind Unit Tests für große Dateien etwas schwierig. Man könnte sicherlich eine große Datei generieren. Letztendlich ist es aber wichtiger die Effektivität des Caches im Betrieb prüfen zu können. Dafür sind Kommandos und Erweiterungen der Administration sinnvoll. Das muss im Rahmen von anderen Tickets passieren.

In diesem Ticket ist es auch wichtig das Verhalten des Caches zu dokumentieren. Die 16 MB Grenze scheint sich nicht auf die Dateien in OPUS zu beziehen, sondern auf den extrahierten Text, der im Cache gespeichert ist.

[j3nsch]

Bei einem 197 MB Beispiel-PDF ist der extrahierte Text 1.3 MB groß. Die 16 MB Grenze bezieht sich auf die Dateien im Cache.

Schaut mal bitte wie groß die Dateien in Eurem Cache werden. Im Prinzip könnt Ihr nach der größten solr_cache----Datei suchen, auch wenn wir dann noch nicht wissen welches Dokument das ist.

Das Kommando tools:extract-file ist jetzt auch auf dem index-Branch und kann verwendet werden, um eine beliebige Datei zu extrahieren und auf Wunsch das Ergebnis in eine neue Datei zu schreiben.

$ bin/opus4 tools:extract-file -o article.txt article.pdf

Später wird es Möglichkeiten geben die Dateien aus dem Cache zu holen, um Prüfungen zu vereinfachen.

Ich möchte wissen, ob wir im Augenblick Dateien im Cache haben, die größer als 16 MB sind. Wenn ich es richtig verstehe, werden diese Dateien trotzdem extrahiert. Deshalb verstehe ich diese Beschränkung nicht.

[j3nsch]

Die größte Cache-Datei, die ich bei uns gefunden habe, ist knapp 7 MB groß (von der HTW). Weitere große Dateien sind dann so 2 bis 3 MB, aber die überwiegende Anzahl bewegt sich < 1 MB.

[j3nsch]

Danke, das ist eine gute Nachricht. Vermutlich werde ich die Begrenzung abschalten und nur noch eine Warnung ausgeben. Wir scheinen ja nicht an die Grenze zu stossen, aber ich will nicht, dass gerade wenn es groß und kritisch wird, der Cache auf einmal sagt, "interessiert mich nicht".

[j3nsch]

Habe auch noch ein wenig bei den Cachegrößen analysiert. Mit den neuen Einstellungen werden nun weitere Dateien indexiert. Auf der Testsystem ist die größte Cachedatei jetzt 9,7 MB. Allerdings erzeugen große Volltextdateien nicht zwangsläufig große Cachedateien.

z.B. Auf dem einen System ist die größte Cachedatei 9,7 MB von der HWR. Der Volltext dazu ist 18MB groß. Dagegen erzeugte ein Volltext mit 153 MB nur eine 171 KB große Cachedatei. Bei einem weiterens Beispiel ist der Volltext 111MB und die Cache-Datei 4,6 MB

[j3nsch]

Ja, Dateien mit vielen Bildern, sind groß und liefern wenig Text. Wenn es ein gescanntes PDF ist, kommt vielleicht gar kein Text dabei heraus. Ich glaube Solr führt kein OCR durch.

[j3nsch]

Unsere Analyse ergab, dass keine solr_cache-Datei größer als 1 MB ist. Die größten Dateien haben sogar konstant nur 1020K. Das ist seltsam. Gibt es hier eine (php-)Konfiguration, die dies begrenzen könnte?

[j3nsch]

Insgesamt klingt das erst einmal ganz gut.