Nginx + PHP-FPM + FastCGI cache configuration for Magento

Question

Some of you may have already noticed the recent Optimizing Magento For Peak Performance white paper released by Magento a few days ago. Even though it was mainly written for EE users, I believe we can use most of the tips for the Community edition as well.

After a good reading, I went ahead and merged their suggested Nginx + fastcgi/proxy cache config with my standard virtual host config for Magento and a few minor improvements. Here’s what I came up with:

fastcgi_cache_path /tmp/fcgi levels=1:2 keys_zone=MAGE:64m max_size=128m inactive=10h;

server {
listen  99999; ## Nginx port
server_name  domain.com www.domain.com;
root  /www/magento; ## App folder
index  index.php;

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires  max;
    access_log  off;
    log_not_found  off;
}

location /index {
    try_files  $uri @fcgi_nocache;
}

location /checkout {
    try_files  $uri @fcgi_nocache;
}

location / {
    try_files  $uri @fcgi_cache;
    if ($cookie_frontend) { return 413; }
    if ($cookie_CUSTOMER_AUTH) { return 413; }
    if ($request_method = POST ) { return 413; }
    error_page 413 = @fcgi_nocache;
}

# Deny access to hidden files
location ~ (/(app/|includes/|/pkginfo/|var/|report/config.xml)|/\.svn/|/.hta.+) {
    deny  all;
}

# Forward paths like /js/index.php/x.js to relevant handler
location ~ .php/ {
    rewrite ^(.*.php)/ $1 last;
}

# Manually purge pages
location ~ /purge(/.*) {
    fastcgi_cache_purge MAGE "$scheme$request_method$host$1";
}

location @fcgi_cache {
    #if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss
    fastcgi_pass  unix:/var/spool/phpfpm.sock; ## php-fpm socket
    include  fastcgi_params;
    fastcgi_connect_timeout  60;
    fastcgi_send_timeout  60;
    fastcgi_read_timeout  60;
    fastcgi_buffer_size  4k;
    fastcgi_buffers  512 4k;
    fastcgi_busy_buffers_size  8k;
    fastcgi_temp_file_write_size  256k;
    fastcgi_intercept_errors  off;        
    fastcgi_param SCRIPT_FILENAME  $document_root/index.php;
    fastcgi_param SCRIPT_NAME  /index.php;
    #fastcgi_keep_conn  on; # NGINX 1.1.14        
    fastcgi_temp_path  /tmp/fcgi2 1 2;

    fastcgi_cache  MAGE;
    #fastcgi_cache_key  "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri"; ## Original
    fastcgi_cache_key  "$scheme$request_method$host$request_uri$http_if_modified_since$http_if_none_match";
    #fastcgi_cache_lock  on 5s; # NGINX 1.1.12
    fastcgi_cache_valid  200 301 302 304 1h;
    fastcgi_hide_header  "Set-Cookie";

    if ($http_cookie !~ "X-Store=1" ) {
        add_header Set-Cookie "X-Store=1; path=/";
    }

    fastcgi_ignore_headers  "Cache-Control" "Expires" "Set-Cookie";
    fastcgi_cache_min_uses  1;
    fastcgi_cache_valid  30m;
    fastcgi_cache_use_stale  updating error timeout invalid_header http_500;
    fastcgi_cache_bypass  $cookie_EXTERNAL_NO_CACHE $cookie_CUSTOMER_AUTH;
    fastcgi_no_cache  $cookie_EXTERNAL_NO_CACHE $cookie_CUSTOMER_AUTH;

    #add_header  X-Cache-Status $upstream_cache_status; # Test
}

location @fcgi_nocache {
    #if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss
    fastcgi_pass  unix:/var/spool/phpfpm.sock; ## php-fpm socket
    include  fastcgi_params;
    fastcgi_connect_timeout  60;
    fastcgi_send_timeout  60;
    fastcgi_read_timeout  60;
    fastcgi_buffer_size  4k;
    fastcgi_buffers  512 4k;
    fastcgi_busy_buffers_size  8k;
    fastcgi_temp_file_write_size  256k;
    fastcgi_intercept_errors  off;        
    fastcgi_param SCRIPT_FILENAME  $document_root/index.php;
    fastcgi_param SCRIPT_NAME  /index.php;
    #fastcgi_keep_conn  on; # NGINX 1.1.14        
    fastcgi_temp_path  /tmp/fcgi2 1 2;

    if ($http_cookie !~ "X-Store=1" ) {
        add_header Set-Cookie "X-Store=1; path=/";
    }
    #add_header  X-Cache-Status $upstream_cache_status; # Test
}

}

After some tests, the results seem impressive via AB, but I’m really not that confident if they are accurate and if the cache system is fully working as expected. Could someone elaborate what is the actual logic behind @fcgi_cache and @fcgi_nocache and the cookies? Who is actually getting the cached pages? The stale cache doesn’t seems to be working when PHP-FPM is turned off (?). I’m a bit stucked and somewhat confused with the different headers I’m getting.

Suggestions anyone??

Answer 1

I know this is an old question, but in case anybody stumbles upon this thread, I just wanted to point out that the newest Magento releases (>=1.13 enterprise & >=1.8 community) will break this nginx caching method.

Once upgraded, and caching is enabled, your users will no longer be able to add to cart if they are looking at a cached page. The reason behind this, is that Magento added in a url form key for the "Add to Cart" button to prevent cross site scripting. With nginx cache turned on, the first URL form key will be cached, and the next set of users will be loading an invalid form key not attached to their session. As far as I could tell, there isn't a way to hole punch nginx cache either, which (to quote ADM) makes "nginx caching absolutely useless". If anybody out there knows if there IS a way to hole punch nginx cache, I'm all ears.

If you continued to use the nginx cache, I highly recommend seeing how you could stand up without it as disabling it, will save you many headaches when upgrading to the newest Magento release.

Answer 2

this type of config is absolutely useless for magento, they used it only to get maximum "dummy" throughput, and this config logics even breaks in few places. you would better configure hole-punching full page cache extension, it will reinsert your dynamic blocks and will keep your site always in cache. there must be as well cache refresh for newly added products and qty changes, etc.