AjaxAndPhpSessions

The portal relies on PHP sessions to cache user data. The catch is that sessions don't necessarily play nice with concurrency. And browser-side AJAX benefits greatly from concurrent requests (and so does the user).

The Problem

While a PHP session is open, it is locked. This makes sense, because you can modify the session data. But it means that another request on the same HTTP session cannot execute until the first closes the session. By default, a session is closed automatically when a request has been fulfilled. Our browser-based Javascript code is able to make multiple simultaneous (and asynchronous) requests to the server for, for instance, aggregate information. All of these requests are part of the same HTTP session. When the first one arrives, processing commences. One of the early things the portal code does is lock and open the session. Once open, the session isn't closed again until the first request completes. This means that the second and third requests from the browser-based Javascript wait until the session lock is freed before they can be processed. This effectively kills any parallelism that might have been gained by contacting multiple aggregates simultaneously.

The Solution

The solution to the problem is to close the session earlier. Specifically, close the session before invoking a call on the aggregate. This allows the actual AM API calls to the aggregate to proceed in parallel. As soon as the session is closed in the first request, the second starts processing. The AM API calls are the most time consuming portion of fulfilling the request, so we benefit from parallelism.

A session is closed in PHP by calling session_write_close().

Summary

Each AJAX handler on the server should close the PHP session as early as it can, but at least prior to invoking an aggregate via the AM API. An AJAX handler is a PHP script that is intended to be invoked by browser-side Javascript.

See amstatus.php for an example. (Hint: search for "session_write_close").