Cache TTL?

Been reading the Grav documentation, and the github pages on my plans to scale for our site with thousands of pages. Is there some sort of cache ttl setting so that objects in cache will automatically get flushed once it reaches a certain time similar to cache ttl settings on memcache? Does the expires setting (default is 7 days) the one I'm looking for?

My plan is to have a main Grav server that has an NFS component and a separate memcached server. I'll setup a cloud based image that has Nginx+PHP7+Varnish, mounts the NFS folder that contains Grav and use that to create instances on demand (Amazon AWS and Google Compute Engine has this capability). All of it will be behind either an Amazon Elastic Load Balancer or Google Load Balancer. Since we'll need to query some posts to generate pages (say an author page with list of stories written by that author), we'll have to write our own backend for Grav that has some sort of SQL server. Set the expires setting change d from 7 days to 5 minutes so that I don't have to manually purge the cache.

I've done a similar setup in the past with other CMS and it worked out pretty well.

the cache: lifetime: 604800 default option in system.yaml is the one you want to override.

Please let us know how your setup goes because typically Grav is not built for thousands of pages.

So my cache: check: method: none, cache: driver: memcache and cache: lifetime: 300 and point my memcache server in cache: memcache: server: x.x.x.x

Thanks!

UPDATE: Placing Grav on an NFS won't work unless you plan to mount as RW. That's not ideal for us. We want the "admin" interface to be hidden or moved to a different URL and mount Grav on a Read-only NFS mount.

What I did was move the cache folder to /tmp and place a softlink like so:

cd /var/www/html
mv cache /tmp
ln -s /tmp/cache

So far, performance has been very good. I'm planning to export an existing Wordpress site and import the contents and perform some tests.

Will there be any problems if I go this route?

Grav also stores/manipulates files into

• /assets if CSS / JS pipelining is enabled
• /backup if you use the CLI/Admin backup facility
• /images (image manipulation cache)
• /logs
• /user/data if you have any Form-plugin form submit saving data, and also used by Admin notifications, Gantry etc.

So, keep this in mind.

Being file based means we need to store things in files, and I actually never tried running it on a read-only file system, so you're really experimenting new stuff here.

experimenting new stuff

^^^^^ which is perfectly fine, but expect things to break :)

• /backup no plans on running backups on the front end web servers
• /user/data no plans on placing any forms for input either

Are the rest safe to soft link on each web servers' temporary folder?

Yes, you can surely symlink them to /tmp/assets, /tmp/images and so on.