Support » Plugin: WP Session Manager » More sessions that visits

  • Resolved George

    (@subscriptiongroup)


    Hello,

    We use your plugin as part of another plugin and we have noticed a large number of sessions in our database. The number of sessions is much higher (about 10 times more) than the visits reported by Analytics.

    This seems to be causing us some isses, as the cron job will only clear 1000/min = 24k/day = 720k/month sessions and surpass that number, meaning there’s garbage accumulating in the database. Appreciate we can change the number or sessions cleared by the garbage collector, but i’d rather not have them there at all.

    I’m trying to understand why there’s such a discrepancy with analytics and i can only think of the following reasons

    1. The plugin we use is creating multiple sessions. Looking at their code, they have

    
    public function init() {
    	$this->session = WP_Session::get_instance();
    }
    

    If i’m not mistaken, this is called on every page load. Would your plugin return a new session if a user navigates through our website and this code is called on every single page?

    2. We have a few uptime monitoring plugins. some are pinging our server and others are loading a page. Analytics excludes those, but i wonder if your plugin would still create sessions for bots? I imagine the answer is yes, so i wonder if you could suggest a way of preventing this?

    Any suggestions would be much appreciated

Viewing 3 replies - 1 through 3 (of 3 total)
  • George

    (@subscriptiongroup)

    It appears my second point was the cause of this. We have a number of monitoring plugins for which a new session is created each time they access our site.

    This is an issue for everyone using uptimeRobot, pingdom or any other monitoring plugin that loads the page instead of just pinging the server.

    Additionally, we have disabled wp-cron to allow for horizontal scaling of our server. We now call /wp-cron.php via a Linux cron job every minute, which also creates a session each time it fires. This script alone, is causing 44k sessions each month, resulting in 88k junk records in our wp_options table.

    A solution for now, is to add a filter to the plugin that uses wp-session-manager where we check the $_SERVER[‘HTTP_USER_AGENT’] and if it’s a bot, we don’t stop a session from being created.

    A more permanent fix, maybe one that’s implemented on your end, would probably be preferred

    • This reply was modified 8 months, 3 weeks ago by  George.
    George

    (@subscriptiongroup)

    Also,

    In a slightly unrelated topic, your plugin appears to write two records on the wp_options table for each session it creates. When used on larger sites, this could be troublesome, as wp_options is a core table and almost every plugin reads and writes from it at least once on every page load, resulting in a large number of queries on each page load.

    When the sessions are deleted every hour, depending on the SQL table settings (InnoDB/MyISAM) it’s likely the table will be locked until the delete query finishes.

    It would probably be preferrable to store the sessions in a new table. This approach is already implemented by WooCommerce and works great, as there is only one record for each session, which keeps things compact and doesn’t spam the core tables. Furthermore, using a simple query, you can identify and delete old sessions in the event the cleanup is not working correctly, or like in our case, you have more sessions created each month, than your default cleanup settings can remove.

    I would therefore urge you to consider moving the session storage outside wp_options and onto your own table.

    Plugin Author Eric Mann

    (@ericmann)

    These issues were the driving force between rewriting things in versions 2 and 3. Version 2.0 introduced a separate database table (for more efficient reads/writes/cleanups). Version 3.0 refactored the entire system to use native PHP sessions instead of a custom object (that was prone to duplicating effort in certain places).

    Almost all of the configuration can now be handled with PHP’s runtime INI configuration, and the custom DB table can be purged as often as needed (even by an external system, if necessary).

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.