CLIENT- Problem: When cache enabled, blank pages returned.
Feb 2007
Intro:
I have a client site that was recently slash-dotted. The client enabled the cache in order to help the situation. Problem was, once cache was enabled blank pages were often returned. So client had to turn the cache off. Site went down.
I have agreed to solve the problem, but my logical skills are not returning definitive results. I am hoping people more experienced in this issue might be willing to help prevent the site from going down the next time they are slash-dotted. The client converted their well-utilised web site to Drupal only recently and they are very interested in finding the way forward in regards to their Drupal investment, and eventually in ways to give-back to the community. I would like to think that there is a way to help them do all that.
The Drupal "cache blank page" issue is well referenced on this site and elsewhere. Definitive solutions are not. I append below some example links on and offsite. I also append an outline of my testing regime. I begin by assuming there is code in an active module that somehow conflicts with other (core?) code to create the blank page situation. I attempt to isolate the particular module or modules by disabling one at a time or enabling one at a time. I get inconsistent results. It seems like there are multiple factors at play.
The site is running v4.7.3. Yes, unfortunately we cannot yet upgrade to 4.7.6 because of particular modules developed in-house. I inherited this site and am working on that situation also.
So I guess the first question is: is there any possibility that between 4.7.3 and 4.7.6 the underlying issue was resolved?
Second question: Anybody got wisdom to share?
Thank you
John
Research: Cache returns blank pages
http://drupal.org/node/59243 various reports of blank page issue being resolved by turning off caching.
http://drupal.org/node/85835 reports problem solved by turning off advanced user module. Client site does not utilise that module
http://drupal.org/node/73872 more reports - no solution except check the modules.
http://drupal.org/node/94148 - similar report of it happening at groups.drupal.org. no solution posted.
http://drupal.org/node/82941 - tracked down to attached_node module – not at Client site.
http://drupal.org/node/85837 - a suggestion about php modules GNU recode or mbstring. Not installed at Client-site. Worth following up?
http://devbee.com/dreaded_blank_page_of_death analysis
http://devbee.com/opcode_cache_for_dummies about opcode cache.
http://blog.gmane.org/gmane.comp.php.drupal.support/month=20050301 related to PHP zlib.output_compression – is off at Client-site.
http://drupal.org/node/88519 use EAccelerator instead?
http://drupal.org/node/2601 improving drupal performance
http://drupal.org/node/85768 optimise mysql
Testing
On test site; observed problem by turning on cache. Load home page OK. Rel-load (ie once in cache) returns blank page.
Unset all blocks. Cleared cache. Load home page Ok, Second load still return blank,
Disabled all in-house modules. Found that Module:Client-1 is essential for the home page, disabling it returns blank page even for admin.
Enabled Module Client-1 but left all other in-house modules disabled. Page loads Ok first time AND SUBSEQUENTLY! Problem is in one or more of the in-house modules.
re-confirmed that turning off all in-house modules (except Client-1) gets rid of the problem. But, by turning one at a time off the problem module could not be found. So the problem arises because of interaction between 2 or more of the modules?
Turned off all in-house modules again and turned them on in sequence from top down on modules page. Problem reappears at Module Client-2. So left that one off and proceeded through the rest. Also reappeared at Module Client-3. But then began to be inconsistent.
Different approach; ran a grep cache on all modules, saved to file.
Found that 3 in-house modules had cache_set code (others had if(maycache)).
I found that these modules had code of the form:
cache_set('recent_comments:'.$_SERVER['REQUEST_URI'], serialize($items), time() + 300);
Taking a bit of a guess, I replaced all instances with:
cache_set('recent_comments:'.$_SERVER['REQUEST_URI'], serialize($items), CACHE_TEMPORARY);
I disabled all in-house modules again (except Client-1) and began turning them on again. Got right through without the problem reappearing.
(Momentary sense of happiness and completion)
If this is confirmed by further testing it seems to indicate that the explicit setting of the expire parameter in cache-Set conflicted with the general cache write setting. ????? (but why would that be?)
Ref: http://api.drupal.org/api/4.7/function/cache_set
Enabled all the blocks and the problem returns…. !!!!!
(Momentary sense of ‘no logic to this at all’).
Further repeats of the module isolation tactics above returned inconsistent results. By the logical divide-and-conquer method the problem module or modules could not be isolated.
Thought: I checked for instances of code containing the string 'cache' hoping to stumble across a problematic line of code. But could the problem be not a bad code line, but instead a missing bit of code; for example is there a place where a cache set should have been used and wasn't? .... lots of code in the 13 client inhouse modules....
