Nginx + PHP-FPM + FastCGI Cache Configuration for Magento

Question

Some of you may already have noticed the recent Magento For Peak Performance optimization published by Magento a few days ago. Although it was mostly written for EE users, I believe that we can also use most of the tips for the community version.

After a good read, I went ahead and combined the proposed Nginx + fastcgi / proxy cache configuration with my standard Magento virtual host configuration and a few minor improvements. Here is 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 using AB, but Im really not sure how accurate they are, and if the caching system is fully working as expected. Can someone figure out what the actual logic of @fcgi_cache and @fcgi_nocache and cookies are? Who actually gets cached pages? Outdated cache does not work when PHP-FPM is disabled (?). I got a little stuck and was somewhat confused with the different headers I get.

Suggestions of someone ???

Answer 1

this type of configuration is absolutely useless for magento, they used it only to get the maximum “dummy” bandwidth, and this configuration logic even breaks in several places. you'd better configure the full page cache extension, it will re-insert your dynamic blocks and will always support your site in cache. You must also update the cache for new products added and quantity changes, etc.

Answer 2

I know this is an old question, but in case someone stumbled upon this thread, I just wanted to indicate that the latest Magento releases (> = 1.13 enterprise and> = 1.8 communities) would violate this nginx caching method.

After updating and caching, your users will no longer be able to add to the cart if they look at the cached page. The reason for this is that Magento added the URL of the Add to Cart button to the form key to prevent cross-site scripting. When nginx cache is enabled, the first key of the URL form will be cached, and the next set of users will load an invalid form key that is not attached to their session. As far as I could tell, there is no way to also cut out the nginx cache, which (to quote ADM) makes "nginx caching absolutely useless." If anyone knows if there is a way to cut out the nginx cache, I'm all ears.

If you continue to use the nginx cache, I highly recommend seeing how you could get up without it, turning it off will save you from many headaches when upgrading to the latest version of Magento.