boost cache pages always regenerated #51

Open
dimon00 opened this Issue May 19, 2012 · 14 comments

Projects

None yet

2 participants

@dimon00

I just installed nginx and ported my drupal 7.14 installation from an apache environment to nginx.
The I configured nginx using the perusio drupal-with-nginx pacake.

The site is working but all the pages are always generated via php and never served from the boost cache.

Looking into the boost cache I see that the file inside are recreated every time a page is accessed.

Any idea?

Thanks

@perusio perusio was assigned May 19, 2012
@perusio
Owner

Hmm. Do you have any type of thing that bypasses the cache? If you're on 7 then there's no anonymous user cookies.

Can you post a debug log somewhere?

@dimon00

I don't have anything that can bypass the cache... at least that I can think of.

The same identical drupal installation, on apache, is using the boost cache so I believe I messed up something in nginx.

Debugging is printing only:
2012/05/20 08:11:47 [notice] 18737#0: signal 15 (SIGTERM) received, exiting
2012/05/20 08:11:47 [notice] 18741#0: exiting
2012/05/20 08:11:47 [notice] 18738#0: exiting
2012/05/20 08:11:47 [notice] 18743#0: exiting
2012/05/20 08:11:47 [notice] 18744#0: exiting
2012/05/20 08:11:47 [notice] 18738#0: exit
2012/05/20 08:11:47 [notice] 18741#0: exit
2012/05/20 08:11:47 [notice] 18737#0: signal 17 (SIGCHLD) received
2012/05/20 08:11:47 [notice] 18737#0: cache manager process 18743 exited with code 0
2012/05/20 08:11:47 [notice] 18737#0: cache loader process 18744 exited with code 0
2012/05/20 08:11:47 [notice] 18739#0: exiting
2012/05/20 08:11:47 [notice] 18737#0: signal 29 (SIGIO) received
2012/05/20 08:11:47 [notice] 18737#0: signal 17 (SIGCHLD) received
2012/05/20 08:11:47 [notice] 18742#0: exiting
2012/05/20 08:11:47 [notice] 18739#0: exit
2012/05/20 08:11:47 [notice] 18742#0: exit
2012/05/20 08:11:47 [notice] 18737#0: signal 17 (SIGCHLD) received
2012/05/20 08:11:47 [notice] 18737#0: worker process 18738 exited with code 0
2012/05/20 08:11:47 [notice] 18737#0: worker process 18739 exited with code 0
2012/05/20 08:11:47 [notice] 18737#0: worker process 18741 exited with code 0
2012/05/20 08:11:47 [notice] 18737#0: signal 29 (SIGIO) received
2012/05/20 08:11:47 [notice] 18737#0: signal 17 (SIGCHLD) received
2012/05/20 08:11:47 [notice] 18737#0: worker process 18742 exited with code 0
2012/05/20 08:11:47 [notice] 18737#0: exit
2012/05/20 08:11:47 [notice] 18768#0: using the "epoll" event method
2012/05/20 08:11:47 [notice] 18768#0: nginx/1.2.0
2012/05/20 08:11:47 [notice] 18768#0: OS: Linux 2.6.32-33-server
2012/05/20 08:11:47 [notice] 18768#0: getrlimit(RLIMIT_NOFILE): 1024:1024
2012/05/20 08:11:47 [notice] 18769#0: start worker processes
2012/05/20 08:11:47 [notice] 18769#0: start worker process 18770
2012/05/20 08:11:47 [notice] 18769#0: start worker process 18771
2012/05/20 08:11:47 [notice] 18769#0: start worker process 18773
2012/05/20 08:11:47 [notice] 18769#0: start worker process 18774
2012/05/20 08:11:47 [notice] 18769#0: start cache manager process 18775
2012/05/20 08:11:47 [notice] 18769#0: start cache loader process 18776
2012/05/20 08:12:47 [notice] 18776#0: http file cache: /var/cache/nginx/microcache 0.004M, bsize: 4096
2012/05/20 08:12:47 [notice] 18769#0: signal 17 (SIGCHLD) received
2012/05/20 08:12:47 [notice] 18769#0: cache loader process 18776 exited with code 0
2012/05/20 08:12:47 [notice] 18769#0: signal 29 (SIGIO) received

@dimon00

I found the problem:
my cache is in:
sites/default/files
while the test is performed in:
cache/normal/$host${uri}_${args}.html

the directory prefix sites/default/files is not used.
If I had it in this way:
try_files /sites/default/files/cache/normal/$host${uri}_${args}.html

the nginx serverves my cached pages.

Any elegant way to fix it? Something I didn't set properly?

Another thing: the content is not compressed. Where can I find the directive to compress my pages?

Thank you

@perusio
Owner

Just add the prefix to the try_files directive.

 # We try each boost URI in succession, if every one of them
# fails then relay to Drupal.
try_files /sites/default/files/cache/normal/$host${uri}_${args}.html  /sites/default/files/cache/perm/$host${uri}_.css /sites/default/files/cache/perm/$host${uri}_.js /sites/default/files/cache/$host/0$uri.html /sites/default/files/cache/$host/0${uri}/index.html @drupal;

It's compressed on the fly. Try it with cURL to check this:

curl -I -H 'Accept-Encoding: gzip,deflate'  example.com 

You should get Content-Encoding: gzip in the reply.

@dimon00

I was able to enable the compression.

But now boost is not working anymore. I added
try_files /sites/default/files/cache/normal/$host${uri}_${args}.html
but, now, it is not make any difference.

I'm using strace and I cannot see nginx searching for the cache files anymore...
should I set something in drupal? Enabling/disabling caching or compression or something?

Thanks

@dimon00

Magically boost started working when I comment this part:

## Error page handler for the case where $no_cache is 1. POST
## request or authenticated.

error_page 418 = @drupal;

## If $no_cache is 1 then it means that either we have a session
## cookie or that the request method is POST. So serve the dynamic
## page.

if ($no_cache) {

return 418; # I'm a teapot/I can't get no cachifaction

}

@perusio
Owner

That's strange. Are you logged in? Is there a session cookie floating around? Try with cURL and see if you get the Boost page. Note that Boost only works for anon users.

@dimon00

My tests are from non-logged sessions.

From curl I get:
X-Header: Boost Helás Avril 1.0
with and without comment on the "teapot part".

The difference is that uncommenting that part the cached page is recreated (I can clerly see the php process working and the cached-file timestamp changed).

@perusio
Owner

I know not enough about Boost now to understand how the update functions. In drupal 6, eons ago, it was by a cron run that replaced the pages that were changed since the last run or by expiring all pages that changed explicitly in a hook_nodeapi.

Are you able to bypass the cache for a POST or when you're logged in, if you comment that part?

@dimon00

Yes, but only uncommenting:
error_page 418 = @drupal;

@perusio
Owner

Are you sure that if a page gets updated it doesn't get replaced in the cache with the error_page directive and cache bypass related directives uncommented?

If you edit a page when saving, the page should be updated. I.e, it should be expired (if you configured Boost to do that). As a simpler alternative to Boost I suggest microcaching. Tune the TTL to your liking. Check the README.

@dimon00

I'm going to look into microcaching.
However, so far, boost seems to work with that part commented.
Save page (and POST in general) seems to work.

I'm going to watch this test environment for some time. I hope it reveal stable because I like the performance that it's showing me. :)

@dimon00

A followup.
Commenting:

if ($no_cache) {

return 418; # I'm a teapot/I can't get no cachifaction

}

prevent authenticted users from getting dynamic pages.

I substituted it with:
if ($http_cookie ~ SESS) {
return 418;
}

like per ticket #18.

So far it seems to work. My page are cached and the cached pages are served only to anonymous user.

@dimon00

Recently I reinstalled a new system and hit the same problem.
Looking at my own thread I wasn't able to figure out a solution so I digged deeply and found a definitive solution (at least for me).
I'm on drupal 7... and it seem my system is giving a cookie even to non authenticated users.

The solution was to edit map_cache.conf
I followed the instruction, inside the file, suggested for drupal 6 user (commented the first part of the file and uncommented the second part).

I suggest to change the documentation a little bit, in the next version of the package, to describe that even drupal 7 installation may need the configuration "without no_anon".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment