Proposal: Reduce session lock contention with opt-in READ_ONLY_SESSION

Proposal: Reduce session lock contention with opt-in READ_ONLY_SESSION

by Adam Eijdenberg -
Number of replies: 3

Hi all, I created the following issue in the tracker yesterday, and Marina suggested that I also create a forum post to discuss:

https://tracker.moodle.org/browse/MDL-58018

The following is copied from the tracker issue:

Background

Many parts of Moodle now result in the browser making parallel requests to the Moodle server.

For example, a home page load on a fresh Moodle installation makes no less than 3 AJAX requests in parallel. Similarly, calls to /pluginfile.php that return HTML, often result in multiple parallel requests for further resources such as JS, CSS, images etc.

Problem Statement

Currently when a request is processed by Moodle, a session is always started, and in order to start that session an exclusive lock is acquired on that session, which, in general, is not released until the server completes processing the request, where it is released by calling write_close() in the shutdown handler (although some pages explicitly release this early).

The result is that even though the browser sends requests in parallel, once the requests hit the server they are in contention with each other, and effectively serialised by the session locking mechanism, resulting in busy spin locks and tying up server resources far longer than actually required. This is particularly apparent when the session lock code is buggy! (see MDL-57477, and PHP memcached issue: https://github.com/php-memcached-dev/php-memcached/issues/310)

Observation

In general, there is often no reason that a session lock is actually needed for cases where the processing of the request does not need any data to be persisted back to the session.

For example, while retrieving the session is nearly always necessary (to check the user is authenticated and authorized to access the selected resource), for serving actual content, such as information about navigation items, where the context is fully specified in the request, or perhaps for serving static content, there is no need to acquire a session lock, where the underlying handler guarantees atomic operations (such as memcached, where a get / set is atomic).

Proposed Solution

We propose a patch that allows:
1. Printing debug information on how long it takes to acquire a session.
2. Ability for a page to declare that it needs only a READ_ONLY_SESSION, where, if supported by the session handler, sessions are acquired without waiting for a lock, sessions are not locked, and calls to write_close() are ignored.
3. Opt-in of some key sources of contention to use this flag.

Looking for feedback

We would appreciate feedback on the validity of this approach, and the linked proposed patch.


The tracker issue (https://tracker.moodle.org/browse/MDL-58018) contains a link to the patch, as well as testing instructions and indicative benchmarks on home page load AJAX request servicing.

Average of ratings: Useful (1)
In reply to Adam Eijdenberg

Re: Proposal: Reduce session lock contention with opt-in READ_ONLY_SESSION

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I am not really an expert on this sort of thing (anyone still in contact with Petr Skoda?) but I thought that ABORT_AFTER_CONFIG means that the session is not opened at all. (For example  https://github.com/moodle/moodle/blob/master/theme/image.php#L30, https://github.com/moodle/moodle/blob/f99313477d7c0e57da72777ff1f0b03c4a998f7b/lib/setup.php#L400 - \core\session\manager::start(); is not until like 785) 

That is used when serving most of the page resources like icons, CSS and JavaScript, and that seems even better than read-only access to the session. 

So, basically, I am not sure about your statement "Currently when a request is processed by Moodle, a session is always started". If that statement is not true, then I don't see a strong case for your read-only session idea.

Overall, what you propose seems like a sound idea. I am just not sure it is really needed (but I could easily be wrong about this).

Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Proposal: Reduce session lock contention with opt-in READ_ONLY_SESSION

by Adam Eijdenberg -

You are correct, in that for non-authenticated content, it is possible today to open a page without opening a session by defining the value that you linked to.

However for any service that requires the user be logged-in, we need read-only access to the session to validate the user is authenticated and authorized to view the resources requested.

Most of the AJAX services (and /pluginfile.php) need to know which user is making the request, and as such need at least read-only access to the session.

Average of ratings: Useful (1)
In reply to Adam Eijdenberg

Re: Proposal: Reduce session lock contention with opt-in READ_ONLY_SESSION

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Thanks for explaining.