On busy sites the plugin becomes very inefficient

>Because the session data is being stored as transients WordPress is attempting to auto load every single one when it starts.

No, the sessions are not stored as transients. They are stored as standard options with autoload set to “no” so that they’re not automatically loaded on every page load for every visitor.

See line 152 of class-wp-session.php.

There was a previous version of the plugin that did use transients, but things have since been rewritten to avoid transients to correct this exact problem. My question would be, which version of the plugin are you using?

Hi Eric
Thanks for your reply. You are right, I am running an older version of the plugin (1.01). I tried upgrading to the latest version but when I do the sessions/site fall over. Did the API change too?

Thanks again

Scott

Yes, the API did change a slightly.

In the older version, sessions were written on every page load, regardless if the data changed in them at all. I worked with some other developers to fix this so that sessions are only written if something changes.

In an ideal (i.e. high-traffic environment), this is what happens:

1. When a new visitor hits your site, a new session is created for them and stored in the database. The session ID, exipiration, and “variant” is stored in a cookie in the user’s browser.
2. When the user comes back to the site, the session is read into the cache (APC or Memcached or something else, depending on your configuration) if it’s still valid.
3. If the session is unexpired, but past the timestamp recorded as a variant, the expiration is updated so things aren’t cleared out too quickly (This is 1 database write to update the exipiration. But it won’t occur on every page load … and you can set the timeout before it does happen through a filter.
4. If nothing changes during this page load (i.e. nothing added to a cart, no options changed), then nothing further happens.
5. When the user revisits your site, the session is loaded from the cache (no roundtrip to the database).
6. If any session data changes, the session is marked as “dirty.”
7. Dirty sessions are re-written to the database at the end of the request.

One big change did occur with the update – sessions are no longer explicitly available in the global namespace as $wp_session. Instead, you’ll need to:

• Explicitly define $wp_session = WP_Session::get_instance(); inside any session-dependent functions.
• OR set a global $wp_session equal to WP_Session::get_instance() inside a function hooked to either init or wp_session_start.

The reasoning behind this change was primarily to keep the global namespace clean and to prevent installing any hidden dependencies in code. A lot of people freaked out that WP_Session was implemented as a singleton in the first place. A second chorus protested to storing it in a global variable as well. This qas a compromise.

Hi Eric
Thanks for such a detailed response. I am going to update my code and see if I can get the plugin running on the latest version as this would solve my current issues and have it behave as I expect.

Feel free to mark this as solved.

Scott