Improve overall performance

[dvglc]

General issue with the current app/database, probably needs to be solved through multiple smaller steps (which can be listed here).

• for works, load only teiHeader and some atomic data into the model - no need to shove around large document trees when we need only the metadata most of the time; tei:text can be side-loaded if necessary
• revise dynamic content injection/creation in html templates (through config.xqm, app.xql, etc.)
• check importing between modules: are there obsolete imports?
• revise index config (once more)
• increase eXist/Jetty/JVM RAM settings?
• reduce calls to i18n functions
• reduce calls to transform:transform
• reduce calls to util:eval
• check if calls to util:expand can be reduced
• minify resources (see below)
• ... ?

[awagner-mainz]

Although I am aware of bad experiences when upgrading exist-db, I would like to suggest we check out exist 5 on the test machine. The reason being that besides the usual "performance improvements" that we may or may not profit from, exist 5 should come with a jetty version recent enough to support HTTP/2: https://webtide.com/introduction-to-http2-in-jetty/

Depending on how smooth the upgrade is, this may be low-hanging fruit.

[awagner-mainz]

Update the following resources:

• jstree.js (downloaded locally, from 3.3.5 to 3.3.9)
• bootstrap (accessed via CDN, update from 3.3.5 to 4.4.1)
• jquery (accessed via CDN, update from 1.11.3 to 1.12.4)
• jquery-ui (accessed via CDN, update from 1.10.4 to 1.12.1)

Minify the following resources:

• resources/js/jstree.js
• resources/js/jquery.tooltipster.js
• resources/css/mirador-combined.css
• resources/css/style_work.css
• resources/css/jquery-ui-1.10.4.custom.css

[dvglc]

It might also help if we enhanced access control, especially of functions ('%private'), in the XQuery code, so as to further reduce interdependencies between functions and modules.

[awagner-mainz]

These cache settings seem to be good (for eXist-db 4, that is!):

• 6GB total memory (Java -Xmx)
• 1GB Cache Size
• 256MB CollectionCache
• (broker) pool max=100

Smaller Cache resulted in more Cache Misses than Hits, larger resulted in memory mgmt overhead.

[dvglc]

Calls to util:eval do not occur in the core of the app, only in services (lod, codesharing). Hence, we would have to modify "external" code to circumvent such calls. Also, since util:eval only occurs in services, it seems not to play a really important role in the functioning of the app. I would thus refrain from replacing util:eval.

Also, I wouldn't know which other function could replace util:eval, and the same applies to util:expand (which actually plays an important role, e.g. in the tei export, data transformations, etc.).

Should we leave those functions as they are?

[awagner-mainz]

Yes, I think we should leave them as they are now. Possibly the performance hits that we meet from time to time are just one or two blocking queries that are problematic in certain call scenarios, so the main thing would be a good stack trace or other log analysis of such an event.