Caching and performance analysis

[ripperdoc]

We need to cache to do a public website, rather than generating template on the fly. But some parts of the current templates, e.g. the header with user name, will be unique for every user and therefore add very little caching value. We need to find a way to cache most of the page (e.g. mainly the articles).

Some more details:

• We can cache in front of nginx, which caches complete HTTP responses. It will try to cache from RAM, then disk. If all RAM is taken by MongoDB, then it will hit disk, and serving direct from MongoDB could be faster. Also, we cannot just cache full response as every webpage currently includes user specific data. This has to be included with Edge Server Inclusion (ESI) which seems not supported in Jinja, or it has to be added with javascript on client. Beware of other potential user specific data. This cache can be done by Varnish, or actually by nginx itself.
• We can cache the finished templates, e.g. after (almost) all processing have been done. This is supposedly done by Jinja2 already, but it's a bit unclear.
• We can cache the database responses using Flask-Cache and e.g. memcached. But this may be of little value - MongoDB already does serve from memory and if memcached is in same machine, what is the point? Note that GridFS responses (e.g. files) can be read from memory if not too big, it's unclear whether it is faster to load the file from GridFS vs loading it from a local file. Should be tested.

Overall, we shouldn't rush to cache anything until we have researched performance. Such as:

• What is page load times for 1st and subseqeuent load?
• What is due latency etc after leaving the server, and what is waiting time within the server
• Is the server memory limited? What is the memory used for? Is the disk used much or not? (overall, right now, we should fit most of Fablr within RAM).

Consider these articles before starting: https://amphtml.wordpress.com/2015/12/16/why-amp-is-fast/ http://flask.pocoo.org/docs/0.10/patterns/caching/ http://brunorocha.org/python/flask/using-flask-cache.html https://pythonhosted.org/Flask-Cache/ https://serversforhackers.com/nginx-caching/

Also, this is fundamental for the total performance: https://developers.google.com/web/fundamentals/performance/

[ripperdoc]

And this link: https://jonsuh.com/blog/need-for-speed-2/

http://stackoverflow.com/questions/135657/tool-to-identify-unused-css-definitions/3113120#3113120

https://www.smashingmagazine.com/2016/12/front-end-performance-checklist-2017-pdf-pages/

[ripperdoc]

New take on caching strategy: Set a flag on g object whether the request is cache-control: public or private. Make it public by default, but any function that in template will result in a variation based on the user, can be publicly cached. So any such function should set the flag to private.

Note that there are other variations that may create stale content in cache, such as outputting HTML that depends on current time (typical example: relative dates).

As the root header includes user data, currently virtually all templates would be private cached. But if we remove that part, and fetch it with jquery, it would make lots of them publicly cached.

What should make a template private cached:

• privilege macro returning true
• anything with g.user
• use of if access_policy.authorize
• Tricky ones:
  • is_owned_by_current_user
  • filtering of posts in lists

Wait, a problem: if we publicly cached the the unprivileged version, won’t the privileged ones also get that, as their request never continues to the Flask server? We can use Vary header for this, but if we put Vary on the cookie/user, it would almost never cache publicly

We can add headers to the Nginx cache key, to ensure we cache different versions. We need to make sure a privileged and unprivileged page gets different cache keys. We could:

• Append to URL
• Set cookie
• Use other sub domain But we can’t store secret info on those pages because there is no security check