Förderjahr 2021 / Projekt Call #16 / ProjektID: 5822 / Projekt: open-pdf-sign
Nachdem wir in den letzten Beiträgen unseren aktuellen Prototyp zum Signieren von PDFs vorgestellt haben, haben wir die Zwischenzeit genutzt, um uns die Geschwindigkeit anzusehen. Da unser Ziel schließlich ist, dass open-pdf-sign durch Serveradministratoren in bestehende Installationen integriert ist, erscheint es uns von großer Bedeutung, dass sich ein möglicher Performanceverlust in Grenzen hält.
Dazu haben wir folgende Variablen durchgetestet:
- Größe von PDFs (in Megabyte)
- Länge von PDFs (in Seiten von DIN A4)
- Anbringung einer sichtbaren Signatur vs Anbringung einer unsichtbaren Signatur
Als Testumgebung haben wir ein Entwicklernotebook verwendet (Apple MacBook Air M1) und einem kleinen Bash-Script für die verschiedenen Kombinationen jeweils 20 Durchläufe durchgeführt, um kleinere Ausreißer in einzelnen Durchgängen zu kompensieren. Für die Signatur verwendeten wir ein selbst erstelltes Zertifikat, dessen Public und Private Key jeweils im “PEM”-Format vorlagen.
Der Aufruf einer mit Debugging-Ausgaben verwendenen Version von open-pdf-sign war beispielhaft wie folgt:
for i in {1..20}; do java -jar openpdfsign.jar -i ../src/test/resources/demo100.pdf -o demo1.pdf -k ../src/test/resources/key_nopass.pem -c ../src/test/resources/cert.pem; done > demo.txt
Gemessen haben wir die Zeit folgender Schritte.
- Startup der JVM
- Parsing der Kommandozeilenparameter
- Konvertierung der Keys vom “PEM”-Format in den von der Bibliothek benötigten Java Keystore
- Anpassung des Java Keystores durch die “dss” Bibliothek
- Initialisieren der Datenstrukturen für die Signatur
- Laden der zu signierenden Daten, Berechnung der notwendigen Checksummen
- Berechnung der eigentlichen Signatur
- Anbringung der PDF-Signatur im geöffneten PDF
Dabei konnten wir feststellen, dass die benötigte Zeit von der Größe des PDFs, aber nicht von der Seitenzahl abhängig war. Nicht alle Schritte jedoch waren variabel, einige benötigten auch immer dieselbe Zeit. Exemplarisch benötigte die Anbringung einer nicht-sichtbaren Signatur eines ca 30 KB großen PDFs etwa 500 Millisekunden, die eines 35 MB großen PDFs 1.300 Millisekunden. Die Anbringung einer sichtbaren Signatur benötigte konstant etwa 150 Millisekunden länger.
Dabei entfielen im Durchschnitt:
- 50 ms auf den Start der JVM
- 20 ms auf das Parsen der Kommandozeilenparameter
- 165 ms auf das Konvertieren der Keys
- 45 ms auf die Anpassung der Keys für die “dss”-Bibliothek
- 75 ms auf die Initialisierung der Datenstrukturen
- Für das Laden der zu signierenden Daten und Berechnung der notwendigen Checksummen: 130 ms beim 30 KB PDF, 400 ms beim 34 MB PDF
- Für die Berechnung der Signatur: 10 ms beim 30 KB PDF, 500 ms beim 34 MB PDF
- Für die Anbringung der Signatur und Speichern des Dokuments: 1 mb beim 30 KB PDF, 95 ms beim 34 MB PDF
Was wir daraus lernen ist einerseits, dass bereits aktuell die Zeitdauer für die Signaturerstellung auf leicht verfügbarer Hardware akzeptabel ist, besonders bei “kleinen” PDFs. Andererseits entfallen von den 500 Millisekunden, die ein PDF zur Signatur braucht, ca 280 Millisekunden, damit mehr als die Hälfte der Gesamtausführzeit, auf Aufgaben, die auch bei Durchführung einer Stapelsignatur nur einmalig durchzuführen sind. Wäre unsere Architektur demnach kein CLI-Aufruf, sondern ein HTTP oder FastCGI-Server, ließe sich die benötigte Zeit ca. auf die Hälfte verkürzen.
Thomas Schreiber
Neben seinem Hauptberuf in der RTR-GmbH beschäftigt er sich als Programmierer von FlexLex mit der Erstellung von PDFs für den Buchdruck, als Mitgründer von NetzBeweis mit digitaler Signatur.