Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

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 22 February 2021 at 18:47

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 22 February 2021 at 13:24

Michael Offner 22 February 2021 at 09:27

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 19 February 2021 at 21:18

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

Details

Assignee

Reporter

Priority

Labels

Fix versions

New Issue warning screen

Before you create a new Issue, please post to the mailing list first https://dev.lucee.org

Once the issue has been verified, one of the Lucee team will ask you to file an issue

Created 19 February 2021 at 21:16
Updated 13 August 2022 at 08:24
Resolved 12 April 2021 at 10:16