William,
On 9/5/23 17:41, William Crowell wrote:
Great post earlier today! This is a super interesting topic to me.
You can find the performance testing results located here:
http://ec2-18-188-185-212.us-east-2.compute.amazonaws.com:8080/web-report/
I did 10 runs with 1000 threads with a ramp up time of 3 seconds for a duration
of 200 seconds. Ignore the 11th run. This is a really simple REST application
with Spring. It just makes an insert into a MySQL table. When I get a moment
I will put my code into GitHub, but again, there is not much to it. You can
find a very similar Spring Boot example with embedded Tomcat here:
https://medium.com/@anil.java.story/embracing-virtual-threads-in-spring-boot-4140d3b8a5a
But he uses JDK 20 with --enable-preview turned on.
The mistake I think I made was that the inserts are not really blocking because
they happen so quickly. Maybe because I did not put enough load in the test?
I have no synchronized blocks in my code. So, it appeared to me that the
inserts were taking twice the amount of time with virtual threads. I think
that extra time is just overhead of pinning virtual threads to a platform
thread and managing the ForkJoinPool.
What is going to happen is that people are going to “flip the
switch”…useVirtualThreads=”true”. They will find that performance will not be
as good as using an operating system thread and abandon virtual threads because
their code does not block.
So, I need to come up with an example where my code blocks and redo the perf
test and prove this out. I don’t know.
Try setting this system property before running your tests and see if it
produces any output on the server while the load test is running:
-Djdk.tracePinnedThreads=full
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org