Reevaluate performance of locking overhead in pc.initApplicationContext() for every request

Description

Now that I've added Lucee to the Techempower language benchmarks, I'm performance tuning the tests-- some of which just hit a hello world page with 512 threads to see how many requests the server can process a second.

I put in a hackaround disk lookup cache to temporarily remove the disk overhead I logged in tickets
https://luceeserver.atlassian.net/browse/LDEV-3288
and
https://luceeserver.atlassian.net/browse/LDEV-3287

This revealed a new bottleneck in Lucee which is shown in the stack trace below. Every request coming into Lucee runs pageContext.initApplicationContext() which employs a KeyLock which single threads this code.

I'm unclear why this needs to be locked, but I would expect that two threads should be able to run at the same time without colliding here so long as the Application context is already created. The Application.cfc listener itself is re-created for each thread, so I'm not sure why it would need locking either. It's worth noting Adobe ColdFusion is outperforming Lucee in these simple tests when it comes to raw request per second throughput. Adobe CF has no locking that I can see of this nature.

Look at finding a way to remove this locking so one request does not need to wait on another request-- especially if nothing is being changed.

Environment

None

Activity

Show:
Brad Wood
February 22, 2021, 6:47 PM

Thanks for having a look at this. Your previous comment seemed to say the locking was "done in the right way" but I see you have added a commit. Did you find an issue with the locking that was incorrect?

Michael Offner
February 22, 2021, 1:24 PM

Michael Offner
February 22, 2021, 9:27 AM

The lock should only be touched if the “onSessionStart“ and “onApplicationStart“ was not be executed yet. And if the lock still apply after a start that of course is a bug, i will investigate.

Last time i checked ACF, this was a bug in their code, with ACF it is possible that when you run multiple threads to a fresh server at the same time, multiple threads will execute the session and application listener. But for a application context the “onApplicationStart“ should only be executed once and the “onSessionStart“ only once for requests with the same CFID, what at least was not the case In ACF last time i checked.

Conclusion, locking is absolutely necessary done in the right way.

Brad Wood
February 19, 2021, 9:18 PM

Note: changing the "Application Listener" setting "Type" to "none" appears to remove the single threaded code in this ticket. This, of course, is not an option for any modern CF application.

Fixed
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Unassigned

Reporter

Brad Wood

Priority

New

Labels

Fix versions