Blank page on some micro-cached pages

Server NGINX
1

Running Nginx 1.5.7 on Freebsd 9.1
with php-pfm 5.5.3

a wordpress site is “micro-cached” , but for some strange reason and not
always , some pages ( wordpress post or pages even 3 or 7 days after
their publication) are rendered for some users ( me and others and not
always the same, with different browsers) as blank pages and the same
connexion can read other cached pages/post with no problems.

The size of the global site in /cache is 72 Kb. Very small indeed.

The bad cached pages are logged like this :
“GET /url HTTP/1.1” 200 31

always 200 as a result code, and 31 for its size… 31 is not the actual
size of the page of course.

If a refresh my local cache ( SHIFT CMD-R) on chrome , the correct page
is reloaded and cached in /cache/x/y/somefile by nginx.

Any help ?

Some config :

fastcgi_cache_path /cache/nginx levels=1:2 keys_zone=microcache:5m
max_size=2000m;
sendfile on;
sendfile_max_chunk 512K;
aio sendfile;
tcp_nopush on;
read_ahead 256K;

open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;

keepalive_timeout 120;
keepalive_requests 10000;

client_max_body_size 2m;

gzip on;
gzip_buffers 48 8k;
gzip_comp_level 4;
gzip_http_version 1.0;
gzip_vary on;
gzip_disable “MSIE [1-6].(?!.*SV1)”;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml
application/xml application/xml+rss text/javascript;

2

Hello!

On Sat, Nov 23, 2013 at 11:00:52AM +0100, Ronald Van A. wrote:

The size of the global site in /cache is 72 Kb. Very small
nginx.

Any help ?

Size is suspiciously small, and I would suggest it’s some error
returned by php.

You may try adding $upstream_cache_status to access log to get
some more details (likely there will be MISS or similar state
there, indicating the response was returned by a php). If it
doesn’t help, some more hints about debugging can be found here:

–
Maxim D.
http://nginx.org/en/donation.html

3

It seems related to every update on a post and the use of the WP plugin
Nginx-Helper

if i add $upstream_cache_status to the log format , nothing is logged.
Should i recompile Nginx 1.5 with some additional modules ?

On the Freebsd port we have :

[ ] HTTP_UPSTREAM_FAIR 3rd party upstream fair module
[ ] HTTP_UPSTREAM_HASH 3rd party upstream hash module
[ ] HTTP_UPSTREAM_STICKY 3rd party upstream sticky module

which do I have to select ?

Le 25 nov. 2013 15:13, Maxim D. [email protected] a crit :

4

Hello!

On Mon, Nov 25, 2013 at 04:47:04PM +0100, Ronald Van A. wrote:

It seems related to every update on a post and the use of the WP plugin
Nginx-Helper

From a description of the plugin, it looks like it is expected to
work with 3rd party cache purge module. It may explain things if
you don’t have the module compiled. Just switching off the
pluging is probably a best solution.

if i add $upstream_cache_status to the log format , nothing is logged.
Should i recompile Nginx 1.5 with some additional modules ?

On the Freebsd port we have :

[ ] HTTP_UPSTREAM_FAIR 3rd party upstream fair module
[ ] HTTP_UPSTREAM_HASH 3rd party upstream hash module
[ ] HTTP_UPSTREAM_STICKY 3rd party upstream sticky module

which do I have to select ?

You don’t need these modules. If $upstream_cache_status isn’t
logged, it’s most likely a problem in your configuration - e.g.,
the log format you’ve modified isn’t used by your access_log
directive.

–
Maxim D.
http://nginx.org/en/donation.html

5

Well nginx 1.5.7 is compiled with this 3 party module :

configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt=‘-I
/usr/local/include’ --with-ld-opt=‘-L /usr/local/lib’
–conf-path=/usr/local/etc/nginx/nginx.conf
–sbin-path=/usr/local/sbin/nginx --pid-path=/var/run/nginx.pid
–error-log-path=/var/log/nginx-error.log --user=www --group=www
–with-file-aio --with-ipv6
–http-client-body-temp-path=/var/tmp/nginx/client_body_temp
–http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
–http-proxy-temp-path=/var/tmp/nginx/proxy_temp
–http-scgi-temp-path=/var/tmp/nginx/scgi_temp
–http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
–http-log-path=/var/log/nginx-access.log
–add-module=/usr/ports/www/nginx-devel/work/ngx_cache_purge-2.1
–with-http_geoip_module --with-http_stub_status_module --with-pcre

Le 25 nov. 2013 17:11, Maxim D. [email protected] a crit :

6

Oups anwser to myself : ADDED the $upstream_cache_status to the LOG :
the page are empty , still a 200 RESULT CODE and a HIT with a 31 byte
size.

myIP - - [25/Nov/2013:17:04:35 +0100] “GET /allairgoo HTTP/1.1” 200 HIT
31 “http://truc/” " Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57
Safari/537.36" “-”
myIP - - [25/Nov/2013:17:04:50 +0100] “GET /allairgoo HTTP/1.1” 200 HIT
31 “http://truc/” " Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_0)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57
Safari/537.36" “-”

Le 25 nov. 2013 16:47, Ronald Van A. [email protected] a crit :

7

Hello!

On Mon, Nov 25, 2013 at 05:24:32PM +0100, Ronald Van A. wrote:

Well nginx 1.5.7 is compiled with this 3 party module :

configure arguments: --prefix=/usr/local/etc/nginx --with-cc-opt=‘-I
/usr/local/include’ --with-ld-opt=‘-L /usr/local/lib’
–conf-path=/usr/local/etc/nginx/nginx.conf --sbin-path=/usr/local/sbin/nginx
–pid-path=/var/run/nginx.pid --error-log-path=/var/log/nginx-error.log --user=www
–group=www --with-file-aio --with-ipv6
–http-client-body-temp-path=/var/tmp/nginx/client_body_temp
–http-fastcgi-temp-path=/var/tmp/nginx/fastcgi_temp
–http-proxy-temp-path=/var/tmp/nginx/proxy_temp
–http-scgi-temp-path=/var/tmp/nginx/scgi_temp
–http-uwsgi-temp-path=/var/tmp/nginx/uwsgi_temp
–http-log-path=/var/log/nginx-access.log
–add-module=/usr/ports/www/nginx-devel/work/ngx_cache_purge-2.1
–with-http_geoip_module --with-http_stub_status_module --with-pcre

So the cache purge is compiled in. It may need to be configured
to work properly with Nginx-Helper plugin though, take a look at
plugin docs.

I suspect the reason for small responses returned from cache (as
your other messages indicate) is a special purge request which
isn’t handled cache purge module but passed back to php, and an
error message returned is cached.

As already suggested, if you are not familiar with nginx
configuration it might be good idea to just switch off the plugin.

–
Maxim D.
http://nginx.org/en/donation.html