Fix 1MB maximum size limit for cache_set()

Created on 18 March 2013, about 12 years ago

Updated 13 March 2025, 27 days ago

Follow up for #1261846-22: Document 1MB maximum size limit for cache_set() → - #24

Problem/Motivation

Orig issue added a comment as a stop gap. Really though, the problem needs to be fixed.

(update this after reading orig issue more carefully. to be done by anyone.)

In a way, it would be better if the cache system handled this. Checking the size of an object or array could be really fast or really slow, depending on the PHP internals. I don't know. If slow, it would obviously be a bad idea. But if it is very fast, than it may be better to move that check into the cache system.

(especially since 1MB isn't actually a hard limit, it depends on configuration), it's to just be careful not to dump massive amounts of data into the cache and assume it'll work. If you checked the size then decided not to write to cache, that'd be worse than throwing errors since it fails silently in that case and the main issue with failing to write like this isn't the PDO exception is the cache miss every request (since usually the first thing to go is the theme registry cache which takes about one second to build).

There's a patch against Memcache to log when writes fail and include the size of the item: #435694: >1M data writes incompatible with memcached (memcached -I 32M -m32) → . That patch isn't ready to go in yet, but we could potentially do something with a try/catch in individual cache backends.

Proposed resolution

TBD

Remaining tasks

fill out this issue summary

User interface changes

No ui changes.

API changes

TBD.

Original report by @marvil07, @valthebald, ...

Actually, by a lot of people. Please read the orig issue: #1261846: Document 1MB maximum size limit for cache_set() →

📌 Task

Status

Postponed: needs info

Version

11.0 🔥

Component

cache system

Created by

🇺🇸United States yesct

Live updates comments and jobs are added and updated live.

Performance
It affects performance. It is often combined with the Needs profiling tag.

Needs backport to D7
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.

stale-issue-cleanup
To track issues in the developing policy for closing stale issues, [Policy, no patch] closing older issues

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 27 days ago →
🇺🇸United States smustgrave
Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024