Import über SWORD wird sehr langsam bei einer höheren Zahl von Dokumenten in OPUS

[j3nsch]

Die Performance der Sword-Schnittstelle nimmt mit der Zahl der Dokumente in einer OPUS-Instanz wesentlich ab.
Wir haben in einem Test ein .zip-File mit einem opus.xml, 2 Volltexten ( ein PDF-File mit ca. 12 MB und ein weiteres XML-File) über die Sword-Schnittstelle importiert.
Die Import-Zeit nahm kontinuierlich zu, anfangs lag sie bei ca. 2 Sekunden, bei einem Füllstand von 30.000 Dokumenten bei ca. 17 Sekunden.
Da mit über 30.000 Verzeichnissen im Volltext-Bereich der Zugriff langsamer wird, habe ich die Volltexte entfernt (die Tabelle document_files geleert und das files-Verzeichnis geleert)
und weitere Importe durchgeführt. Die Import-Dauer blieb weiterhin im gleichen Bereich. Der Verzeichniszugriff scheint demnach die Verzögerung nicht zu verursachen, die Zahl der Dokumente an sich scheint das Problem zu sein (auch ohne Volltexte).

Ich hänge den Verlauf der Import-Zeit mit steigender Zahl von Dokumenten an und außderdem Auszüge aus dem opus.log und dem mysql-slow-query.log an. In letzterem konnte ich (allerdings nicht bei jedem Import) langsame Zugriffe auf dem document_xml_cache feststellen, obwohl die importieren Dokumente den Status serverState="inprogress" hatten.

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

[j3nsch]

Ich denke es ist kein Problem mit SWORD an sich, sondern vermutlich ein Problem, dass bisher nur in diesem Kontext zum Tragen kommt.

[j3nsch]

Der Primary-Key für die document_xml_cache Tabelle ist ja eine Kombination aus ID und XML-Version. Ich denke, das heißt, dass bei der Löschoperation (siehe slow_query.log oben) kein Index mit nur der ID vorhanden ist, wodurch die Operation immer langsamer wird. Sehe ich das richtig?

CREATE TABLE IF NOT EXISTS `document_xml_cache` (
  `document_id` INT UNSIGNED NOT NULL,
  `xml_version` INT UNSIGNED NOT NULL,
  `server_date_modified` VARCHAR(50) NULL,
  `xml_data` MEDIUMTEXT,
  PRIMARY KEY (`document_id`, `xml_version`)
)
  COMMENT = 'Caches XML for Opus_Document objects.';

[j3nsch]

Der Kontext spielt bestimmt eine Rolle. Was könnten denn die begrenzenden Faktoren sein - außer immer langsameren Datenbank-Operationen?

Wir haben den Test mit einem separaten Datenbank-Server durchgeführt, da spielen sicher das Netzwerk eine Rolle, allerdings ist der Effekt genauso sichtbar bei einer lokalen Datenbank. Die Datenbank arbeitet bei den Importen intensiv, die Last hält sich allerdings in Grenzen, d.h. unser Server ist hier durchaus ausreichend dimensioniert. Für weitere Hinweise bin ich natürlich dankbar.