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

Reply via email to