Great Results with Nginx Cache

[.Nuno.]

Hi,

Since I'm not a programmer and I don't know the heart of IPB, this is somehow hardcoded ...
As usual, use it has you own risk ... test, test, test. This should be considered experimental, so test it before using in a prodution environment.

Attached to this post is a ZIP with two files, purge.php and purge.sh.

purge.sh, from https://github.com/perusio/nginx-cache-purge
This file should be placed outside root folder and nginx user (usually www-data) should be able to execute it.
Your php configuration must allow shell_exec command and you must have curl installed.

So, first place this file for example /usr/local/bin/purge.sh and chmod 755

Next, edit purge.php and change _NGINX_PURGE_SCRIPT and _NGINX_CACHE_PATH constants to reflect your configurations/locations.

Upload purge.php to your root folder where index.php is.
Edit index.php and before ipsController::run(); add

include_once( 'purge.php' );

Now, test, test, test! Note ... this only works with furls and nginx conf should use try_files without args

try_files $uri $uri/ /index.php

At this time, Board Index isn't purged, sorry!

[.Nuno.]

Hi,

Here is two purge.php files, one with a minor fix and the other will purge board index too.

As ususal, test, test, test!

PS: You should rename purge_home.php to purge.php

[Elly]

I will be trying this possibly tomorrow.

Since purge is working now with SSI to track guests (who hit the cache), does this mean in theory I can set cache_valid to 365d? (or infinity)?

[.Nuno.]

I will be trying this possibly tomorrow.

Since purge is working now with SSI to track guests (who hit the cache), does this mean in theory I can set cache_valid to 365d? (or infinity)?

I would say yes, but test first and increase from time to time to evaluate it's behavior.
Note that only topics/forums are purged, so if you set cache to high, other pages like gallery/members/etc will remain static until expires.

Test and report please!

[maddog107_merged]

Nuno, Thanks for the scripts. Not that we want you to redo all the work you did but did you try the Flush Cache module (http://wiki.nginx.org/3rdPartyModules) http://labs.frickle.com/nginx_ngx_cache_purge/ As opposed to doing it through system calls? I just worry about the security implications of allowing system calls through a webserver. Thanks I will let you know how my testing goes with Nginx.

[.Nuno.]

Hi,

Yes I did and thank you for asking!

The problem I faced is related to multiple pages per topic and per forum.
Using that module it's hard to remove all pages from a topic and from a forum since in a topic with lots of posts we have lot's of pages because the way furls are implemented.

You have pagination, you have sort, etc ... all these furls are hard to find.

With this shell script you are uging grep regular expressions to list all files from a topic and from a forum.

I understand your worries, but I didn't found a way to remove purge all pages with the purge module.

[maddog107_merged]

I see. So just to be clear then your current setup purges the WHOLE topic even though only the last page has been modified correct?

So say

http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/

http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/page__st__20

http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/page__st__40

My reply now will modify page__st__40, but the cache will need to purge all 3 pages?

[.Nuno.]

I see. So just to be clear then your current setup purges the WHOLE topic even though only the last page has been modified correct?

So say

http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/

http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/page__st__20

http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/page__st__40

My reply now will modify page__st__40, but the cache will need to purge all 3 pages?

Yes ... you're correct. Do the following, edit purge.sh and comment line 73:

rm $i

Then run purge.sh from the command line and see the files listed with the pattern you want to remove from the cache.

[maddog107_merged]

Ok thanks for the info.

So what is the reason to not purge just the last page? Its caching the whole URL so it knows say


http://community.invisionpower.com/topic/364153-great-results-with-nginx-cache/page__st__20
has been unchanged since just the __40 was updated. Since caching is for guests I dont think they can change how many posts per page so we are safe from that point. Would there be any other scenario that you thought of that would get stale if we didnt do the wildcard?

The reason I ask is because we have multiple topics that are almost 1,000 pages long and it would be a shame to have to purge out all 999 pages for the 1 page that has been changed (usually the last)

[.Nuno.]

Hi,

I can try to just purge the last page, but all forums need to be purge to reflect the new topic order.
Agree or you have other suggestion?

Thanks

[Elly]

I have implemented the initial configuration posted. However it seems as though cookie is still being sent in the header for guests.

Set-Cookie: session_id=c5e567a84c8129e104c6c21669395d84; path=/; httponly

Set-Cookie: modpids=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

I have Set-Cookie in fastcgi_cache_ignore from your settings. In theory Set-Cookie should be stripped before it enters the cache?

If I curl -I initially, X-Cache header is MISS. If I do it again, it's a HIT. However on the same URL in my browser, will be MISS. Thus I think cookie is making it have separate cache for each session_id?

Edit: The session_id is different when using fastcgi cache depending on browser/IP

I have reverted back to the Varnish config. session_id using varnish is the same across browsers/IP, hence all requests are hitting the same copy, not individual separate copies (like fastcgi cache - so although it looks like it's hitting cache when requesting from one source, it doesn't apply to everyone else)

[.Nuno.]

I have implemented the initial configuration posted. However it seems as though cookie is still being sent in the header for guests.

Set-Cookie: session_id=c5e567a84c8129e104c6c21669395d84; path=/; httponly

Set-Cookie: modpids=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

I have Set-Cookie in fastcgi_cache_ignore from your settings. In theory Set-Cookie should be stripped before it enters the cache? If I curl -I initially, X-Cache header is MISS. If I do it again, it's a HIT. However on the same URL in my browser, will be MISS. Thus I think cookie is making it have separate cache for each session_id? Edit: The session_id is different when using fastcgi cache depending on browser/IP I have reverted back to the Varnish config. session_id using varnish is the same across browsers/IP, hence all requests are hitting the same copy, not individual separate copies (like fastcgi cache - so although it looks like it's hitting cache when requesting from one source, it doesn't apply to everyone else)

Hi, Can you test adding:

fastcgi_hide_header Set-Cookie;

to the configuration?

Thanks

[Elly]

'Set-Cookie' is not present in the header after putting in fastcgi_hide_header. , but logged in users cannot log out at all.

.Nuno., are you getting the same session_id problem on your site? I wonder if there is something wrong with my config.

[maddog107_merged]

I have implemented the initial configuration posted. However it seems as though cookie is still being sent in the header for guests.

Set-Cookie: session_id=c5e567a84c8129e104c6c21669395d84; path=/; httponly

Set-Cookie: modpids=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

I have Set-Cookie in fastcgi_cache_ignore from your settings. In theory Set-Cookie should be stripped before it enters the cache?

If I curl -I initially, X-Cache header is MISS. If I do it again, it's a HIT. However on the same URL in my browser, will be MISS. Thus I think cookie is making it have separate cache for each session_id?

Edit: The session_id is different when using fastcgi cache depending on browser/IP

I have reverted back to the Varnish config. session_id using varnish is the same across browsers/IP, hence all requests are hitting the same copy, not individual separate copies (like fastcgi cache - so although it looks like it's hitting cache when requesting from one source, it doesn't apply to everyone else)

Interesting, I did not even bother to make sure it was working (was just benchmarking). I will try it out later and let you know if I see the same issue.

Since you are already on Varnish by any chance could you try to run an 'ab' benchmark to see how it compares? Or is it a live site?

[maddog107_merged]

Hi,

I can try to just purge the last page, but all forums need to be purge to reflect the new topic order.

Agree or you have other suggestion?

Thanks

I agree that when someone posts a reply to a topic, the following need to be flushed:
Last page of topic
Index page of topic's category forum
Index page of forum in general

I just dont belive we need to flush all pages in the topic itself, assuming we are caching each page seperatly

[Elly]

Sorry it is a live site. I saw a benchmark before and nginx was faster, however in real world I think the difference is negligible.

Would like to get fcgicache working though, reduces a source of problems on the server. :)

To reiterate, varnish does send a Send-Cookie/session_id as well, but if it's from the cache (HIT), it's the same value across all browsers. For nginx, if it hits the cache, the session_id is different, at least for me between command line and browser. They are hitting separate caches of the same URL, possible due to session_id being diff

[maddog107_merged]

Hmm strange, I am seeing similar results as Elly. If I do it command line (curl or ab -v 2) I see something like this:

---
LOG: header received:
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Wed, 04 Jul 2012 19:47:31 GMT
Content-Type: text/html;charset=UTF-8
Connection: close
X-Powered-By: PHP/5.4.4
Set-Cookie: session_id=fa34d845ea0dbfedeb933533157a2da1; path=/main; domain=.bellazon.com; httponly
Cache-Control: no-cache,must-revalidate, max-age=0
Expires: Tue, 03 Jul 2012 19:47:31 GMT
Pragma: no-cache
X-Cache: MISS

----------- SECOND RUN ----------

LOG: header received:
HTTP/1.1 200 OK
Server: nginx/1.2.1
Date: Wed, 04 Jul 2012 19:47:40 GMT
Content-Type: text/html;charset=UTF-8
Connection: close
X-Powered-By: PHP/5.4.4
Set-Cookie: session_id=fa34d845ea0dbfedeb933533157a2da1; path=/main; domain=.bellazon.com; httponly
Cache-Control: no-cache,must-revalidate, max-age=0
Expires: Tue, 03 Jul 2012 19:47:31 GMT
Pragma: no-cache
X-Cache: HIT


Viewing from browser with HttpFox I see this (no matter how many times I refresh).


(Status-Line) HTTP/1.1 200 OK
Server nginx/1.2.1
Date Wed, 04 Jul 2012 19:50:17 GMT
Content-Type text/html;charset=UTF-8
Transfer-Encoding chunked
Connection keep-alive
X-Powered-By PHP/5.4.4
Set-Cookie session_id=5e5bbc6e0cd009ee8950311855f01fee; path=/main; domain=.bellazon.com; httponly
Cache-Control no-cache,must-revalidate, max-age=0
Expires Tue, 03 Jul 2012 19:50:17 GMT
Pragma no-cache
X-Cache BYPASS
Content-Encoding gzip



Not sure why its BYPASS instead of MISS.




CHROME dev tools works better, but still its a miss even though this was ran AFTER the hit from the command line.


Cache-Control:no-cache,must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html;charset=UTF-8
Date:Wed, 04 Jul 2012 20:04:28 GMT
Expires:Tue, 03 Jul 2012 20:04:28 GMT
Pragma:no-cache
Server:nginx/1.2.1
Set-Cookie:session_id=9c590c92b1ade4c16a35fd9e07bd766d; path=/main; domain=.bellazon.com; httponly
Transfer-Encoding:chunked
X-Cache:MISS
X-Powered-By:PHP/5.4.4


Cache-Control:no-cache,must-revalidate, max-age=0
Connection:keep-alive
Content-Encoding:gzip
Content-Type:text/html;charset=UTF-8
Date:Wed, 04 Jul 2012 20:04:59 GMT
Expires:Tue, 03 Jul 2012 20:04:28 GMT
Pragma:no-cache
Server:nginx/1.2.1
Set-Cookie:session_id=9c590c92b1ade4c16a35fd9e07bd766d; path=/main; domain=.bellazon.com; httponly
Transfer-Encoding:chunked
X-Cache:HIT
X-Powered-By:PHP/5.4.4

[.Nuno.]

Where you login when doing this test?

Bypass means the request is not cached.

Can you show both headers from the cache?
I would like to see if the KEY is the same.

Thanks

Edit: Have you disabled GZIP on IPB?

[maddog107_merged]

^ I updated my post to include Chrome dev tools. And yes I am logged out. And GZIP is indeed disabled.

[maddog107_merged]

you mean sent and received header? Or what do you mean by "show both headers from the cache"?

[.Nuno.]

you mean sent and received header? Or what do you mean by "[color=#282828][font=helvetica, arial, sans-serif]show both headers from the cache"?[/font][/color]

Edit you /var/cache/nginx (or other location) / files that where generated for the same url with different browsers and you'll find the headers saved.

[maddog107_merged]

I had already looked in there /var/cache/nginx. It saves two different MD5 (hash) files one from the CURL one from the browser itself. I tried to look at them but they are binary files.

[.Nuno.]

You can edit with vim or nano.

[maddog107_merged]

[root@BZ2 c4]# ls

0c4ba76cefc78ad363cf133d3a461c45

[root@BZ2 c4]# pwd

/var/cache/nginx/one/5/c4

óôO^@^@^@^@ÿÿÿÿÿÿÿÿF°ôO^@^@^@^@<90><86>ñ^Z^@^@U^@s^A^@^@^@^@^@^@

KEY: httpGETwww.bellazon.com/main/index.php

^A^F^@^A^A^V^B^@X-Powered-By: PHP/5.4.4^M

Set-Cookie: session_id=7868616e6fd0c02867f04f3d215a2a14; path=/main; domain=.bellazon.com; httponly^M

Content-type: text/html;charset=UTF-8^M

Cache-Control: no-cache,must-revalidate, max-age=0^M

Expires: Tue, 03 Jul 2012 21:06:14 GMT^M

Pragma: no-cache^M

^M

<!DOCTYPE html>








[root@BZ2 58]# ls

347ac9565f53feee2e706e5cffec2587

[root@BZ2 58]# pwd

/var/cache/nginx/one/7/58


¾³ôO^@^@^@^@ÿÿÿÿÿÿÿÿ:°ôO^@^@^@^@Ãü<86>ì^@^@G^@e^A?" cla

KEY: httpGETwww.bellazon.com/

^A^F^@^A^A^V^B^@X-Powered-By: PHP/5.4.4^M

Set-Cookie: session_id=09790235087019164a918f92dc0fe49a; path=/main; domain=.bellazon.com; httponly^M

Content-type: text/html;charset=UTF-8^M

Cache-Control: no-cache,must-revalidate, max-age=0^M

Expires: Tue, 03 Jul 2012 21:06:02 GMT^M

Pragma: no-cache^M

^M

<!DOCTYPE html>

[.Nuno.]

The Keys aren't the same ... / is different from /