Skip to main content
We are currently experiencing a higher than average ticket volume and as such our responses may be delayed. Searching on our Help Center articles or going to our Community is also a great resource for answers.

Time to live for the cached content

Comments

5 comments

  • cPRex Jurassic Moderator

    Hey there!  Are we certain that the directory size itself is a good way to monitor that value?  It might be better to check the timestamp on the actual cached files, although it would seem odd if they were all getting purged at once.

    Is it possible the user clicked the "clear cache" button in the cPanel interface while they were testing something on the site?  That would show up in the /usr/local/cpanel/logs/access_log as this entry:

    10.3.17.223 - cptest [05/07/2024:20:00:19 -0000] "POST /cpsess0975853681/execute/NginxCaching/clear_cache HTTP/1.1" 200 0 "https://10.2.35.128:2083/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0" "s" "-" 2083
    0
  • Dimitris Andrikopoulos

    Hello,

    I checked the file "/usr/local/cpanel/logs/access_log" and the last time the cache was cleared was on 30-Apr. I have configured "access_log off;" the file "/etc/nginx/nginx.conf". If I change that setting to the below, will I be able to see any purge requests on the NGINX cache?

     access_log  /var/log/nginx/access.log  main;

    0
  • cPRex Jurassic Moderator

    I wouldn't expect that setting to relate to the log purge.  We may need to see a ticket on this behavior as I'm not finding other similar reports of the time to live value not working properly.

    0
  • Dimitris Andrikopoulos

    I'm using the Screaming Frog crawler to craw 500 pages of the website. At the first crawling attempt I noticed that the size of the proxy_cache_path directory "/var/cache/ea-nginx/proxy/myuser" was growing fast. At subsequent crawling attempts, I didn't notice significant change of that size. In addition, the response times of the pages were much better at the second crawling attempt than the first attempt (see below screenshot).

     

    This behavior showed me that the caching mechanism of NGINX Reverse Proxy worked fine for my implementation, so far. However, the size of the directory "/var/cache/ea-nginx/proxy/myuser" reached 2.5 - 2.9 GB, and within the day it became again a few kilobytes. When I crawled again the website, the response times were again worse. This was an indication that the cached content was somehow cleared. So, things don't look like to work properly. With the below lines in the configuration file "/etc/nginx/conf.d/users/myuser.conf" I would expect that the cached content would live for 3 days (72 hours).

    Is there some other configuration I should check regarding the time-to-live for the cached content of NGINX?

    proxy_cache_path /var/cache/ea-nginx/proxy/andrikop levels=1:2 keys_zone=andrikop:10m inactive=7d max_size=10g use_temp_path=off;
    server {
        location / {
            ...
            proxy_cache_valid 200 301 302 72h;
            ...
        }
    }

     

    0
  • cPRex Jurassic Moderator

    I'm honestly not sure - the previous recommendations were the only information I had about this issue as that is the most likely configuration option.  At this point we need to se a ticket so we can test this directly on your server.

    0

Please sign in to leave a comment.