Feature request: performance improvements for `processHtml()`

Features
1

Problem

I’ve been looking at the live trace of my pages, and it appears that processHtml() is doing a roundtrip to the database for every link (and image and attachment) in the HtmlArea.

Solution

Can processHtml() be optimized so that it can query the database once for a list of all the content (one database roundtrip), and uses that list of content to build the urls – saving us a lot of back and forth to the database?

4 Likes
2

I was thinking more about this, and menu-lib might also get a performance improvement in the same way.

Instead of retrieving one-and-one content, it might be enough to make one database roundtrip per level.

E.g on level 2, one could query for the children of all the contents on level 2, and get back all the contents on level 3 in one database query roundtrip.

3

There is definitely room for improvement. We are investigating possible improvements for link rendering performance - most likely by some sort of caching: second-level and/or static page cache.

Unfortunately the idea about minimizing roundtrips will most likely not work:

  • XP data is local on each node, there is usually no network roundtrip involved (it is only true when data is not disabled on frontend nodes)
  • getByIds is very much like multiple getById - on Elasticsearch level and performs almost as good/bad as serial calls to get by single ids