Performance degradation with webjars locator

[apellegr]

Hello,
we see a significant regression on performance on some of Arm servers which is introduced by this patch (I didn't test on x86):

commit 91f55a4f7134409a832435de2c6df231102d5898 (HEAD -> head-2)
Author: Dave Syer <[email protected]>
Date:   Wed Nov 27 08:32:30 2024 +0000
 
    Versionless webjars (again)
 
    Spring Boot 3.4 supports the webjars-locator-lite which in turn
    supports native images, so we are back to versionless URLs for
    webjars assets in templates.

The performance drop introduced is quite severe, going from 3.3k req/s on this little test to about 0.7k req/s.

user@PetClinic-test:~$ numactl -C 16 wrk -c 1 -t 1 http://localhost:8080 -d 60
Running 1m test @ http://localhost:8080
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     1.36ms   15.88ms 359.72ms   99.44%
    Req/Sec     3.37k   453.34     3.79k    93.80%
  200156 requests in 1.00m, 579.75MB read
**Requests/sec:   3335.91**
Transfer/sec:      9.66MB
user@PetClinic-test:~$ numactl -C 16 wrk -c 1 -t 1 http://localhost:8080 -d 60
Running 1m test @ http://localhost:8080
  1 threads and 1 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency     2.59ms   16.94ms 374.89ms   99.41%
    Req/Sec   700.85     80.00   780.00     93.13%
  41660 requests in 1.00m, 120.67MB read
**Requests/sec:    694.05**
Transfer/sec:      2.01MB
user@PetClinic-test:~$

These are the steps to repro on Ubuntu.
Server:

    sudo apt update
    sudo apt install numactl wrk maven openjdk-17-jdk
    git clone https://github.com/spring-projects/spring-petclinic.git
    cd spring-petclinic/
    ./mvnw package
    numactl -C 0-7 java -jar target/*.jar

Client:
numactl -C 16 wrk -c 1 -t 1 http://localhost:8080 -d 60

[dsyer]

That's unfortunate as it was supposed to be a performance improvement. For me it's only a factor of 2x worse (not 4x) not on arm, but I'm not sure why that's a problem.

[dsyer]

Did some digging and the problem comes from ResourceUrlEncodingFilter which is conditionally added to a Spring Boot app if webjars locator is on the classpath. Even the new faster webjars-locator-lite doesn't solve the problem that for every rendered URL the classpath has to be checked for an existing resource. I've raised the issue with the Framework team, so let's see what they say.

UPDATE: according to @bclozel the filter should be caching all its work, so that doesn't seem to be happening. He's going to look into it.