Feature #5715
closedPDF Caching
100%
Description
Das rendern (zusammensetzen aus mehreren Quellen) eines PDF kann lange dauern. Vorschlag fuer ein Caching:
- Es gibt ein Cache Verzeichniss, fileadmin/protected/cache.
- Beim zusammenbauen (Parameter in _link) kann neu ein Caching Token bestehend aus 'tablename/id/column'-Tripples (falls kein 'columnname' angegeben ist, wird 'modified' genommen ) angegeben werden.
Cache Verzeichnis (konfigierbar in QFQ) fileadmin/protected/cache/ ... AS _pdf (AS _link) d|p:header&r=567|f:fileadmin/protected/file1.pdf|f:fileadmin/protected/file2.pdf|cache=[<tablename>/<id>[/column]][,...] >> md5=34857sdjk4387564387y fileadmin/protected/cache/34857sdjk4387564387y.pdf (modified datum) ... AS _savePdf schreibt in den Cache ... AS _saveZip schreibt in den Cache f: AS _zip
EN: Beispiel Syntax- 10.sql = SELECT CONCAT AS _link
Zusammengesetzten PDF ins cache Ordner ablegen falls noch nicht existent. Von dort wird der Download ausgeführt (Bisherige Funktion führt keinen Download aus, sondern öffnet PDF im Browser). Das im Cache abgelegte File wird bei nochmaligem Aufruf mithilfe vom Check des MD5 Hashes überprüft auf veränderten Inhalt, falls ja: Das File im Cache mit dem neu zusammengesetzten PDF ersetzen und (Download ausführen) PDF öffnen.
Für die Identifikation des richtigen Files im Cache wird der Filename verwendet ('d:MergedPdf'. Muss in dem Fall angegeben werden, da ansonsten kein Abgleich möglich. Als Default wird immer output.pdf ausgegeben.)
Ein Check auf den Erstellungsdatum des Files im Cache wäre überflüssig, da bei Änderungen das File sowieso erneut erzeugt werden muss.
Infos:
MD5 Hash check for changes: https://www.w3schools.com/php/func_string_md5_file.asp
Check auf Erstellungsdatum, stündlich (eigentlich überflüssig, da bei Änderung immer File ersetzt werden muss): if (time() - filemtime("test.pdf") > 60*60*1){unlink("test.pdf");}
- Von allen Source Reference Angaben (filename, url) wird ein MD5 Hash gebaut. In dem Hash ist kein Timestamp enthalten, denn dann wuerde die zuletzt gecachte Datei nicht ueberschrieben werden bei einem Update.
EN: Ich konnte nirgends finden dass ein Timestamp im MD5 Hash möglich ist.
- Unter dem <cache Verzeichnis>/<MD5> wird die fertig gerenderte Datei gespeichert.
EN: Für was steht <MD5>? Das zusammengesetzte PDF File oder nur ein abgelegter Hash?
- Von allen Filename wird der 'modified'-Timestamp, und die Timestamps der aufgeloesten 'tablename/id/column'-Tripple, verglichen mit dem modified timestamp der Datei '<cache Verzeichnis>/<MD5>'
EN: Nicht mehr benötigt in unserem Fall? Lösung sollte ohne DB Eintrag möglich sein soweit ich das verstanden habe.
- Gibt es min. einen Timestamp der neuer ist als der der gerenderten Datei, wird die Datei neu gebaut.
EN: Gleiche Aussage wie beim letzten Punkt? Timestamp nicht mehr nötig da kein DB Eintrag.
- Es gibt ein Token im Link, welches beim rendern dazu fuehrt das das PDF auf Vorrat (im Cache Verzeichnis) gebaut wird.
- Das Render passiert am besten asynchron, gesteuert ueber rabittmq oder mqtt (#5851)
EN: Allgemein zum Cache Feature: Hat nichts direkt mit dem Zip zu tun oder? Welches ja angefragt wurde für Medtool. Eine Anwendung vom Mode: Zip mit _link kann eine aneinanderreihung von PDF Files als ein Zip herausgeben. Dieser wird als Dowload angeboten. Besser: Etwas wie _saveZip könnte einmal Stündlich mit Autocron ausgeführt werden um einen abgelegten Zip File zu refreshen. Der Zusammenhang mit dem Caching wäre hilfreich wenn wir dies direkt über _link ermöglichen wollen, da viele PDFs gemerged werden müssen (ca. 30 bis 40). Wäre es da nicht schlauer mit einem Autocron und per neuem _saveZip diese abzuspeichern und nicht direkt per Download über _link anzubieten?
Files
Related issues
Updated by Carsten Rose over 5 years ago
- Related to Feature #5851: Queue System implementieren: MQTT, RabbitMQ added
Updated by Carsten Rose about 5 years ago
- Related to Support #6357: Generiertes PDF auf Server abspeichern added
Updated by Carsten Rose about 5 years ago
Evtl. koennte die Funktion von #6357 mit diesem Ticket gemerged werden.
Updated by Carsten Rose over 4 years ago
- Priority changed from Normal to High
- Target version changed from 55 to 146
Updated by Benjamin Baer over 4 years ago
Ich glaube das my problem hat auch mit der Annotate Tabelle zu tun. Die ist bereits ueber 2G gross. Den FabricString auf MediumBlob von MediumText zu aendern scheint bereits deutliche verbesserungen auf einigen Masken zu geben.
Updated by Carsten Rose over 4 years ago
- Target version changed from 146 to QFQCD19 - waere gut
Updated by Carsten Rose almost 4 years ago
- Status changed from New to Some day maybe
Updated by Carsten Rose almost 4 years ago
- Status changed from Some day maybe to New
Updated by Carsten Rose over 3 years ago
- Target version changed from QFQCD19 - waere gut to next6
Updated by Carsten Rose over 2 years ago
- Target version changed from next6 to next4
Updated by Enis Nuredini 10 months ago
- File mergedPdf.png mergedPdf.png added
Folgende Situation beim Medtool:
Dies ist das PDF welches für eine Dissertation zusammengesetzt wird. Nun werden von allen Dissertationen jeweils dieses zusammengesetzte PDF in einem einzigen Zip benötigt. Ich glaub damit das sauber geht müssen diese zusammengesetzten PDFs schon mal als PDF abgespeichert werden mit _savePdf . Danach käme auf diese neuen Files ein _link mit M:zip zum Einsatz. Vielleicht übersehe ich hier etwas aber ich sehe keinen Umweg die zusammengesetzten PDF zuerst irgendwo zu hinterlegen bevor ich auf die dann mit dem Mode Zip mergen kann. Der Einsatz vom Cache spielt in dem Fall eine Nebenrolle, da die merged PDFs irgendwo schon existieren müssen für den Zip Export.
Updated by Carsten Rose 10 months ago
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Applied in changeset typo3-qfq|cbe687f2eb48e86e015d10efe651ccb7b33cbf19.
Updated by Carsten Rose 9 months ago
- Related to Feature #15208: Best Practice: a) Funktion Path::join() besprechen, b) cache added