Nginx Fastcgi Cache

[carnagel]

Hi,

Would it be possible to get a full list of url parameters, cookies and so forth to exclude from cache when setting up fast_cgi cache - regardless of how many strings/cookie values I add to no-cache, the site ends up having issues with pages in different languages being cached (tried adding the language cookie/disabling all languages apart from EN etc - no luck), api returns gibberish (tried adding api string to exclude, no luck), logged in user pages being cached (again added the cookie and strings to exclude, no luck)

I think fast_gci caching with exclusions is by far the best way to manage the imagehost caching for large sites (works beautifully on other sites/cms), but have been unable to find a definitive listing of how to actually use it for chevereto.

Thanks.

 

[Rodolfo]

The only thing that really needs to be cached in Chevereto are the language files and since 3.6.1 the system uses translation cache that will highly decrease the impact on the system: https://chevereto.com/blog/translations-and-other-improvements-in-3-6-1/

Chevereto v3.6.1 use basic file-based cache but with OPCache the whole thing is insanely fast. You can check the demo website cache stats here: http://demo.chevereto.com/opcache.php just notice how many hits saves in files that are requested more often.

Bottom line is that you should use OPCache for any PHP-thing and everything else is just an extra.

 

[carnagel]

Oh I agree that it works flawlessly with php opcache - I'm getting 99.999 hit rate %, and running a site with say 100-500k images, you wouldn't need to look any further.

It's just that once you get over the 1.5-2 million mark on large HD images, even with opcache, it starts really grinding, even on top hardware (and I'm talking serious load balancing using multiple dual high-end xeon ssd front ends with dedicated mysql servers and raid10 storage arrays), which brings me back to my original question....

I noticed in another thread you made the remark that nginx micro-caching is very effective for large imagehosts - and I 100% agree, I'd just like some concrete guidelines on exactly what urls/cookies need to be excluded to make the fast_cgi caching actually work please. Especially the api.

Thanks.

 

[Rodolfo]

In that case you will need to perform a code search for $_SESSION, $_COOKIE and setcookie. I'm afraid that I didn't used a naming convention here so you will find mixed keys. In the future I think that I could change all to CHV_* to make this easier. Sadly there are a lot of keys that I can't handle like the ones related to the vendor classes (like Google, Twitter, etc.) so actually I don't think that you should cache sessions at all because that data is absolutely logged-user related.

Secondly, in a system like Chevereto you should not cache /login, /signup, /search, /settings, /dashboard, etc. Actually I think that the only stuff that you can safely cache is the /pages route and that is about everything. Everything else needs manual cache handle and you can't just point the thing to cache a listing because it can cause issues due to customized lists depending on the logged user.

I don't think that FastCGI-cache will show considerable advantages compared to OPCache in Chevereto. You have to keep in mind that Chevereto is a very lightweight system so is not the same as Drupal or Wordpress where you must cache about everything. In those systems is also safe to cache everything because you don't have dynamic list, posts, pages, etc. In Chevereto you have dynamic lists everywhere.

That said, the truly advantage of some sort of cache could be at database level so the system doesn't need to do queries + parsing over and over. But in Chevereto is not something that you simply turn on/off from your server, it needs to be done manually at script level, with manual data store like "store this listing for the user x for t period of time" which is totally different from cache "/explore?page=2"

 

[carnagel]

Thanks Rodolfo that has given me a lot to work with going forwards, appreciate it.

 

[neoark]

@carnagel any luck figuring out what to exclude?

 

[neoark]

@Rodolfo for vanish and cloudflare setup is it same toIgnore Query String for caching these formats https://support.cloudflare.com/hc/e...ns-does-CloudFlare-cache-for-static-content-? I am seeing lot of querry strings on fonts and css.

 

[Rodolfo]

Query strings in statically files are intended to control the cache stuff on each consecutive update. Without those strings, CloudFlare isn't able to update the static cache to reflect the latest version of those resources.

If I don't include those, a manual cache refresh is needed (or a ping to the CloudFlare api). Since CloudFlare isn't the only reverse proxy provider, I use the query string method.