Cache ServletContext#getResource()

Hi everyone,

it has been reported yesterday that XWiki 16.10.3 is approximately a factor two slower than XWiki 15.10.16 for certain (common) types of requests. After a bit of profiling, I found that the most likely reason for the performance difference is the move to Jetty 12 for the standalone distribution, as according to IntelliJ’s profiler, 46% of the running time is spent in ServletContext#getResource() in 16.10.3 while this is only 10% in 15.10.16. I don’t know how these numbers look like for Tomcat. As we also offer Debian packages for Jetty, and they are the best option for installing XWiki 16.10.x on current Debian versions, this definitely also affects production setups, so I think we should fix this.

I did a bit of research and found this ServletContextCache which says “ServletContext methods can be somewhat slow” so I assume that introducing a cache for ServletContext would indeed be a good idea. Unfortunately, the mentioned cache doesn’t seem to support Jakarta so using it won’t be an option (and the LGPL v3 license is also a bit unfortunate).

So I propose that we introduce our own cache for ServletContext. This cache only resolves string paths to URLs, so it shouldn’t use much memory. The main question is when to invalidate the cache. In normal production setups, no invalidation should be needed. However, it development setups it might be beneficial to allow invalidating the cache. In general, it might be interesting to have some “development” mode in XWiki where we, e.g., allow invalidating caches more easily. Some ideas discussed with @tmortagne in the chat:

1. Introduce a configuration option for a development mode. By default, this option is false unless the XWiki version is a SNAPSHOT version, then it is true by default.
2. If the development mode is on, allow bypassing the cache when the client is sending the Cache-Control header with value no-cache similar to what we already do for other caches. This is normally sent on a force-reload. See xwiki-platform/xwiki-platform-core/xwiki-platform-container/xwiki-platform-container-servlet/src/main/java/org/xwiki/container/servlet/internal/CacheControlRequestInitializer.java at 6b2557d966c7eb7fc633092084ac4c7da37e4e45 · xwiki/xwiki-platform · GitHub and related code.

We could also discuss respecting this Cache-Control header in general only in development mode, also for, e.g., the Velocity cache.

An alternative could be to disable the cache completely in development mode, but this would mean that by default development snapshots would appear much slower, and we wouldn’t test the cache - and we wouldn’t benefit from the cache on CI (for integration tests).

Any opinions?

1 post - 1 participant

Read full topic