Update: we’ve been setting the page cache to 2000. So far, we experience no obvious large increase of memory consumption but will monitor it further.
The cache works well, meaning that viewed pages are returned from the cache. I verified this by checking the PostgreSQL database log output where generally none of the initial SQL (executed with an empty cache) are to be found during page load any more. So far, so good.
However, there is an exception, and it appears this might be related to the fact that our page loads sometimes still are slow even if cached (still often > 2 sec). This happens especially if pages are accessed shortly after another (< 10 sec). My guess is this is due to unfinished processes caused by the previous page load, and there is indeed one SQL which is still executed when the page was cached:
2023-01-09 10:47:51.044 GMT [8058] LOG: execute S_7: select baseobject0_.XWO_NAME as col_0_0_ from xwikiobjects baseobject0_ cross join xwikistrings stringprop1_ where baseobject0_.XWO_CLASSNAME=$1 and baseobject0_.XWO_ID=stringprop1_.XWS_ID and stringprop1_.XWS_NAME=$2 and stringprop1_.XWS_VALUE=$3
2023-01-09 10:47:51.044 GMT [8058] DETAIL: parameters: $1 = 'XWiki.OIDC.ClientConfigurationClass', $2 = 'configurationName', $3 = 'default'
To be more precise, this statement is executed identically (!) hundreds of times (!) during page load and in the 5-10 seconds after.
The statement obviously belongs to the OpenID Connect extension we recently installed to enable Google SSO.
We are using the in-wiki method, defining a page (in the root namespace) with an object of the XWiki.OIDC.ClientConfigurationClass. Exactly the one which is queried above.
However, it is rather unclear why this is executed identically for so often, and also, why this page is not cached itself. Maybe something in our custom Velocity / CSS / JS code is causing this, but no clue what this can be.
Or it is the fact that we have 17 subwikis. (The SQL posted above is sometimes executed in the public schema and sometimes in the subwiki’s schema - where the object does not exist.) However, the extension is intended for usage in a farm so this should not be the issue.
Any ideas?
We also tried to get rid of the in-wiki-config, to remove this page and its object and to put everything into the xwiki.properties.
However, this attempt failed because we couldn’t get rid of sending custom claims to Google, which Google does not accept (any more). A similar problem is described in this thread: Claims must have a single object value 'id_token'
The in-wiki-configuration, so far, is the only method which worked for us to get the Google SSO enabled, so we need to live with that somehow.
If I should open another thread for this OpenID Connect question please let me know.