spring-projects
Performance degradation with webjars locator
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
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.
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.