SessionManager clones cache store, resulting in unnecessary redis connections.

[TheLevti]

Laravel Version

12.45.2

PHP Version

8.4.16

Database Driver & Version

latest phpredis with aws redis serverless 7.x

Description

We have tight infra and performance constraints and specific applications limit the amount of max open connections to redis to 1. Now thats not a problem, we just configured a single redis connection (default), and updated all config/ files to use the default redis connection when redis is used by any of the laravel components.

Now the problem appears specifically only with the Sessions component. It has code that for some unknown reason clones the store, which in turn clones the redis store. Like in many cases session is checked before anything else and that means that a session will clone a redis store that has no connection established yet. Then any other component that needs to use redis (e.g. cache), will also establish a new connection, because session manager took off with a clone. This is a waste of resources in high performance applications.

Can someone explain why we do the following? And if there is no real reason, can I propose a fix for it? Open for suggestions.

// SessionManager::createCacheHandler()
clone $this->container->make('cache')->store($store),

->

// Illuminate\Cache\Repository::__clone()
$this->store = clone $this->store

Screenshot shows on the left the session being retrieved from redis and then we fail establishing a connection to redis (under sendRequest to get the http cache) even though we already have one.

Steps To Reproduce

Set redis.pconnect.connection_limit=1 in your redis.ini

Load any endpoint that reads/writes sessions and also does some other redis operations in the controller, like using the Cache component. Ensure session connection and cache connection are equal.

[TheLevti]

Solution

Remove unnecessary clone operation in SessionManager::createCacheHandler() that causes duplicate Redis connections when using cache-based session drivers.

Problem

When using cache-based session drivers (redis, memcached, dynamodb, apc), the SessionManager::createCacheHandler() method clones the cache Repository:

// Illuminate\Session\SessionManager::createCacheHandler()
return new CacheBasedSessionHandler(
    clone $this->container->make('cache')->store($store),
    $this->config->get('session.lifetime')
);

This triggers Repository::__clone(), which in turn clones the underlying store:

// Illuminate\Cache\Repository::__clone()
public function __clone()
{
    $this->store = clone $this->store;
}

Impact on Redis connections

With Redis (phpredis), this creates a race condition:

1. Session middleware runs first, before any other cache use
2. Clone happens while RedisManager::$connections is empty
3. Session's cloned store establishes connection via pconnect()
4. Subsequent cache operations through the original store may attempt a second pconnect() call

In environments with strict connection limits (e.g., redis.pconnect.connection_limit=1), this results in:

RedisException: Connection limit reached

Even without strict limits, this wastes resources by potentially creating unnecessary connections.

Analysis

Why was the clone added?

The clone was likely intended for:

• Isolation between session and cache operations
• Preventing session from affecting other cache consumers
• Defensive programming

Why the clone is unnecessary

1. CacheBasedSessionHandler never mutates Repository state

   The handler only calls read operations:

   $this->cache->get($sessionId, '');          // read
   $this->cache->put($sessionId, $data, $ttl); // write
   $this->cache->forget($sessionId);           // delete

   None of these modify the Repository's internal state ($default, $events, $config).

2. Cache operations are atomic at the store level

   The underlying RedisStore, MemcachedStore, etc. are designed for concurrent access. Multiple consumers can safely share a Repository.

3. Inconsistent with other session drivers

   • DatabaseSessionHandler doesn't clone the database connection
   • FileSessionHandler shares the filesystem instance
   • Cache-based handlers should follow the same pattern

4. Undermines Laravel's singleton design

   CacheManager and RedisManager are registered as singletons specifically to share resources. The clone creates a parallel object graph that defeats this design intent.

5. The propagating clone in Repository::__clone() is problematic

   Even if Repository isolation was needed, automatically cloning the underlying store is overly aggressive and causes connection-related side effects.

Solution

Remove the clone from SessionManager::createCacheHandler():

protected function createCacheHandler($driver)
{
    $store = $this->config->get('session.store') ?: $driver;

    return new CacheBasedSessionHandler(
        $this->container->make('cache')->store($store),
        $this->config->get('session.lifetime')
    );
}

Testing

• Verified that CacheBasedSessionHandler works correctly without the clone
• Confirmed Redis connection reuse when session and cache share the same store
• No behavioral changes to session read/write/destroy operations

Breaking Changes

None. This is an internal optimization that doesn't change the public API.

Related

• Fixes connection limit issues in high-performance environments
• Improves resource efficiency for cache-based session drivers
• Aligns session handler behavior with other Laravel components

[TheLevti]

Patch fix has been rejected.

Its ok, but please include the fix in a minor or major release.

Many are not aware that they are creating 2 redis connections for each request for the same connection label.

This is a quite big performance/resource penalty in environments where every millisecond counts.

Would welcome it a lot if laravel pays more attention to improving performance as well and not just on adding convenience stuff.

[marius-ciclistu]

Why is this considered a breaking change?

[TheLevti]

Why is this considered a breaking change?

The proposed change is not breaking anything, its rather fixing what is already broken (see PR description, it would be breaking if we would just remove the clone statement) and aligning all stores to work the same with cached sessions. I highly doubt anyone is expecting 2 parallel connections being established for the same label. Also its fully covered by tests. As explained one connection label must not cause multiple connections in parallel, thats whats happening here.

So maybe just overcautionsness by the maintainers, or they maybe don't have the time to deal with it?

But honestly if this is not getting fixed, I will soon give up trying to contribute performance fixes/improvements for the community. Its getting really hard justifying in my company why we are keep going with php and laravel, when company sponsored performance fixes/improvements are rejected without good reason. Its not the first time tbh.

Of course we found multiple fixes for this issues for ourselves, but we would like to give back and fix it for the whole community.

[marius-ciclistu]

To be honest I tought of including this for my client't custom framework inspired by laravel also, but your AI form of describing the issue gave me second thoughts. We don't use redis but memcache. Also I don't know yet all the implications of session and cache using the same connection.

[marius-ciclistu]

Have you tried the persistent true for phpredis to see if it avoids multiple connections?

[TheLevti]

We are always using persistent connections. The problem is that we explicitly want to make all components use a single connection, so everything is configured to use default. With this bug, we encounter a race condition that forces 2 connections to be created for default.

You have all settings available to configure which redis connection should be used for what. If you want a dedicated connection for sessions, you just set SESSION_CONNECTION to the redis connection you have configured. But honestly there is no downside using a single connection to the same redis instance for everything. It would maybe make sense if you store sessions in redis1 and cache in redis2. Otherwise, its just a waste of connections as redis is always single threaded.

[TheLevti]

There are 2 solutions that we found work:

set the phpredis persistent id to a fixed string. That ensures that the same host will always resolve into an already existing connection if its already there. (we went with this)

Another solution is to force connect at bootup, but thats bad practice as you may not need redis on every request you handle.

But knowing how badly laravel performs in high throughput environments, it was quite important for us to provide a lasting solution that is applied to everyone else. As said, I am sure majority is not even aware that they are opening 2 connections for every request when using redis sessions.

[marius-ciclistu]

php artisan cache:clear would clear the sessions or not with a persistent connection or with your changes?

[TheLevti]

Depends on your configuration. Has nothing to do with the issue or the changes.