In other words, /blog1/a-random-post will serve a nginx-cached page (timestamp from half an hour ago, for example, reloading does not change timestamp), but /another-random-post generates a new page every time it’s accessed (timestamp updates with every reload).Īny clue why this would be happening? Any help would be greatly appreciated. They all serve pages correctly, however only the two WordPress installations in subdirectories correctly cache for non-logged in visitors (registered users don’t see cache ever, as expected). I’ve setup three WordPress installations under a single domain: Help will be appreciated as we have around million hits in a day and during peak loads we get very high load on Mysql and PHP-FPm process.Īwesome tutorial, thanks for putting it together. Q3: Is supercache in nginx better then Nginx with Fastcgi cache ? I tried varnish but had lot of problem ? What does this directive mean ? is it in MB or minutes ? what is the ideal value, Our aim is to keep the cache for many days and it should refresh only when some does a new posting. Is 500m in MBs or minutes ?what is the ideal value for it and for inactive ? If ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") įastcgi_cache_path /data1/nginx-cache1 levels=1:2 keys_zone=WORDPRESS:500m inactive=420m # Don't cache uris containing the following segments # POST requests and urls with a query string should always go to PHP Server_name access_log /var/log/nginx/ Įrror_log /var/log/nginx/ Now make changes to /etc/nginx/sites-available/file so it looks like one below: #move next 4 lines to /etc/nginx/nf if you want to use fastcgi_cache across many sitesįastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m įastcgi_cache_key "$scheme$request_method$host$request_uri" įastcgi_cache_use_stale error timeout invalid_header http_500 įastcgi_ignore_headers Cache-Control Expires Set-Cookie single or Multisite (with subdirectory/subdomain/domain-mapping) fastcgi_cache related configuration will remain similar. No matter how you are using WordPress, i.e.
It looks like we have more than 6GB at our disposal! Our server has 32GB RAM by the way, so 6.3GB is close to 20% Nginx Config You will see output like below: Filesystem Size Used Avail Use% Mounted on To verify it, run command df -h /var/run.
Its generally 20% of your total RAM size. If you are going with RAM, make sure you check size of /var/run folder. If you do not have ample RAM you can pick any other location. You need give Nginx a folder store fastcgi_cache content. I will recommend using /var/run on Ubuntu as its mounted as tmpfs (in RAM). If you want more control over your cache purging rules, you can play with different purging options it provides. Just activate it, go to its settings and turn on “Enable Cache Purge” option. Apart from other features, it provides cache purging options.
#Install cacti on mac osx with nginx install
So install Nginx helper plugin from WordPress plugin repository and activate it. But Nginx cannot automatically find out which page to purge and when to purge? Sudo apt-get install nginx-custom Install Nginx Helper PluginĪbove step ensures that Nginx can purge a page from its fastcgi_cache selectively. Reinstall nginx with fastcgi_cache purge module support sudo add-apt-repository ppa:rtcamp/nginx
Otherwise, if you are on Ubuntu with default Nginx installation, you can run following commands to install nginx with fastcgi_cache_purge module.
If you see nginx-cache-purge in output then you already have it. If you have installed Nginx by following our guide, then support for fastcgi_cache_purge should be already there. You can test it by running following command: nginx -V 2>&1 | grep nginx-cache-purge -o Prerequisites Check if your nginx has fastcgi_cache_purge module Without this 3rd party module, cache won’t be updated if you create/edit any post/page in WordPress. So we need to rely on third-party nginx module. Nginx has built-in support for fastcgi_cache but it doesn’t have mechanism to purge cached content built-in. Rather than asking a complex PHP-MySQL application like WordPress to do some extra work for caching, we will ask light-weight Nginx to cache WordPress content on its end. Today, we will use an altogether different way of caching! In first part of this series, we have seen many combinations of different WordPress setup with different caching plugins. Easyengine (ee) note: If you are using easyengine, you can accomplish everything in this article using command: ee site create -wpfc