We were having trouble on a site that has a lot of traffic, with PHP timing out, and the web server not recovering. It was odd, because the site doesn’t have very much interactive parts, and in mostly served from the cache… except it wasn’t being cached at all!
The site makes heavy use of Pods for custom post-types, and that is hardly an issue, but in this case Pods was setting a session ID via cookie, which of course meant each time a page is visited it is “new”, and bypasses the cache. Suddenly our high volume of traffic is hitting the database and rendering each page on every load, and honestly I was surprised it survived for as long as it had.
My research turned up two issues that were relevant: Replace all session and session_id usage #2237 and 2.4.3 prevents browser caching #2542.
#2237 refers to a change that could possibly fix this issue, but is ongoing. #2542 contains the fix, though I wasn’t able to track where it came from, as it wasn’t provided in the referenced conversation.
define('PODS_SESSION_AUTO_START', false);
Because I couldn’t source this seemingly undocumented config, I hopped on the Pods Slack instance, where Jim True and Bernhard Gronau verified that it was exactly for this use case. Pods has a feature I don’t use, wherein one can produce a front-end form to submit content directly into a Pods-created post-type, and the sessions are a security feature.
Turning off the sessions did the trick, and soon the site was being delivered from the cache.
Bonus tip
In discussing the Pods forms, I mentioned I used Gravity Forms, with the Gravity Forms + Custom Post Types plugin. They recommended Pods Gravity Forms Add-On. When I asked about the difference, they explained the Pods add-on can handle relationship fields. That is very cool! 