Does enabling caching introduce unnecessary round-trips to cache store?

[frutality]

Hello,

My setup is pretty basic:

1. Database (PG) as main settings storage.
2. Caching is enabled. Default cache storage is also same DB at the moment.
3. One GlobalSettings class.
4. No multi-tenancy, nothing custom.

If during request we need GlobalSettings several times, there are several round-trips to Cache Storage. For example:

$something = app(GlobalSettings::class)->something; // imagine this in middleware

$somethingElse = app(GlobalSettings::class)->somethingElse; // imagine this in controller

$somethingDifferent = app(GlobalSettings::class)->somethingDifferent; // imagine this in service, or model, or anywhere

If cache is enabled, debugbar says there are 3 hits:

hit settings.App\Infrastructure\Settings\GlobalSettings
hit settings.App\Infrastructure\Settings\GlobalSettings
hit settings.App\Infrastructure\Settings\GlobalSettings

3 x hit settings.App\Infrastructure\Settings\GlobalSettings (0%) 0μs

And 3 queries listed at "Queries" tab:

select * from "cache" where "key" in ('laravel_cache_settings.App\Infrastructure\Settings\GlobalSettings')
select * from "cache" where "key" in ('laravel_cache_settings.App\Infrastructure\Settings\GlobalSettings')
select * from "cache" where "key" in ('laravel_cache_settings.App\Infrastructure\Settings\GlobalSettings')

If cache is disabled, debugbar says there is only one DB hit:

select "name", "payload" from "settings" where "group" = 'global' // DatabaseSettingsRepository.php#28

If application and DB (and/or cache store) are on different machines, something like that could quickly add to total response time, in my experience. Especially if network is not fastest or experiencing high load.

Question is, does caching works like intended in this case? Maybe I have misconfigured something?

[rubenvanassche]

This should normally fix the issue: #350