Changes between Version 1 and Version 2 of Ticket #55206, comment 2
- Timestamp:
- 02/23/2022 02:07:57 PM (4 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #55206, comment 2
v1 v2 3 3 Thank you for the response. 4 4 5 I agree `SAVEQUERIES` is working as intended, but it's not uncommon for it to be on by default in a development environment. It could potentially lead to confusing time spent by inexperienced devs who've coded themselves into a memory limit corner. For this one, I'd solve it using the constant to initialize a `$save_queries` property of `$wpdb`, same as how `$show_errors` is. It would make it useful for devs to be able to grab just the queries from their set of calls. 5 I agree `SAVEQUERIES` is working as intended, but it's not uncommon for it to be on by default in a development environment. It could potentially lead to confusing time spent by inexperienced devs who've coded themselves into a memory limit corner. For this one, I'd solve it using the constant to initialize a `$save_queries` property of `$wpdb`, same as how `$show_errors` is. It would make it useful for devs to be able to grab just the queries from their set of calls. Even with that in place, I'd probably still look to cap the number of queries saved at some reasonably large number like 10,000 just to prevent the issue altogether. 6 6 7 7 For the cache one, two days ago I learned of a function called `wp_suspend_cache_addition`. Thank you for that. Totally solves the scenario. Still, it's conceivable someone doing generally best practices using the common api could find themselves in OOM territory. For this one I'd solve it with garbage collection. If a group in the cache exceeds some memory threshold, it gets pruned.