Replies: 13 comments
-
Could this be related to the introduction of cache table? Example
vs
The cache implies also an insert that might not be caught by the DebugQueryListener. in env these 2 default to database not to file in L11 and L12: |
Beta Was this translation helpful? Give feedback.
-
We do not use database as a cache store |
Beta Was this translation helpful? Give feedback.
-
@Nutickets In L10 the env name is CACHE_DRIVER while in 11 is CACHE_STORE. This change defaults the cache to database if you did not declare CACHE_STORE after upgrade in env. PS. Thanks for this issue. We found out what was not ok with our demo page for L 12 thanks to you. |
Beta Was this translation helpful? Give feedback.
-
Are you sure that this isn't caused by changes made to the |
Beta Was this translation helpful? Give feedback.
-
The only changes to our We have not explicitly set a value for Since opening this issue, we've manually reverted the L11 changes to // AppServiceProvider.php
public function register()
{
// HOTFIX: *temporarily* revert the mysql connector logic to what it was pre-laravel-11. More info inside.
$this->app->bind('db.connector.mysql', MySqlL10Connector::class);
} The contents of As soon as we deployed that change, the idle database connections started dropping and continued to do so for the following 12 hours until it reached the baseline level that we are used to seeing pre L11 upgrade: |
Beta Was this translation helpful? Give feedback.
-
I believe you should try enabling |
Beta Was this translation helpful? Give feedback.
-
It kinda looks a lot like there's an RDS proxy bug here. |
Beta Was this translation helpful? Give feedback.
-
Even on Laravel 10 you were opening and closing connections excessively but not using persistent mode. On Laravel 11, it looks like there's some kind of RDS proxy bug that's leaving around dangling connections, possibly due to the more efficient connection bootstrap process uncovering a bug in RDS proxy. |
Beta Was this translation helpful? Give feedback.
-
'mysql' => [
'driver' => 'mysql',
'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',
'prefix' => '',
'prefix_indexes' => true,
'strict' => false,
'engine' => null,
'timezone' => '+00:00',
'options' => extension_loaded('pdo_mysql') ? [
// NB: for SSL RDS proxy connections, we don't need a cert because the proxy manages them using ACM.
PDO::MYSQL_ATTR_SSL_CA => env('MYSQL_ATTR_SSL_CA'),
PDO::MYSQL_ATTR_SSL_VERIFY_SERVER_CERT => env('MYSQL_ATTR_SSL_VERIFY_SERVER_CERT', false),
] : [],
],
True but we're delegating that responsibility of connection pooling to RDS proxy - at least thats our interpretation of why we may not need to use persistent mode.
I was totally ignorant to how RDS proxy pooled connections until this sudden spike tbh, but now I understand connections are 'pinned' (i.e. no longer re-usable) when certain Although I'd be surprised if it were that simple, because then 100% of RDS proxy users on L11 would have this same spiking problem that we experienced. |
Beta Was this translation helpful? Give feedback.
-
I think you may be the only RDS proxy user who uses Laravel 11... |
Beta Was this translation helpful? Give feedback.
-
That's not quite how that works. You still need a persistent connection between the PHP app and the proxy server. |
Beta Was this translation helpful? Give feedback.
-
@GrahamCampbell we also use RDS proxy so we should not update from 10 then? |
Beta Was this translation helpful? Give feedback.
-
@macropay-solutions I don't think that's necessarily true. With the right config, the upgrade should be fine. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Laravel Version
11.44.2
PHP Version
8.2.18
Database Driver & Version
MySQL 8.0.40 on RDS via RDS Proxy
Description
When we deployed our Laravel 10 -> 11 upgrade in April, there was a spike in DatabaseConnections through our RDS proxy which has since persisted (screenshot included below). We did not deploy any other changes to the AWS infrastructure - there were a high number of 3rd party Laravel package upgrades alongside it as expected with any major framework upgrade, however there's nothing within those upgrades that stand out as something that could introduce such a universally impactful change.
We have suspicions that it could be related to this change: https://github.com/laravel/framework/pull/50044/files but haven't yet A/B tested this as it's not feasible for us to rollback to L10 at this stage. The connections seem to be idle and it may be possible for us to workaround the issue by playing with the RDS proxy idle connection timeout settings, but preferably would like to understand the root cause.
Steps To Reproduce
I'm not sure exactly how to describe reproduction steps at this time, just raising awareness in case there are other people who have noticed a similar outcome or can perhaps educate me on how to navigate this situation as it feels possibly like a time bomb since our application experiences extremely high traffic surges during large event launches.
Beta Was this translation helpful? Give feedback.
All reactions