Jinja templates are from disk... we are blocking?

[gnat]

Preamble

To avoid confusion this is NOT the same as "Asynchronous template rendering" here: https://www.starlette.io/templates/#asynchronous-template-rendering

This is NOT an issue about separation of logic from templates.

Issue

Unless Jinja environment.is_async is true, it appears Jinja 3 runs render() in a blocking way.

Jinja 3: https://github.com/pallets/jinja/blob/main/src/jinja2/environment.py#L1259

Starlette: https://github.com/encode/starlette/blame/master/starlette/templating.py#L37

Discussions

Previously:

• Use async version of jinja #727 (comment)

@tomchristie You mentioned:

And yes we could be using threadpool'ed loading, which might well make sense, although it's actually not super clear in practice.

Any new information here?
@alex-oleshkevich Since you previously observed this, any comments?

More previously:

• WIP/RFC: templating: do not require request in context #502
• Default jinja2 setup. #196

Thank you for any insight!

[lovelydinosaur]

Short: I've not seen enough evidence that a sync disk accesses are actually a significant benefit in practice. There's a bunch of overhead with the thread-pooling. Probably wouldn't want to act on this unless there was a compelling motivation.

[alex-oleshkevich]

@gnat if I am not mistaken, Jinja reads from disk only once and then caches template into a compiled function. So no intensive disk IO happens. Use auto_reload=False in production.

[gnat]

Great responses! Can confirm your comments are accurate as of this writing.

Jinja's cache is a {} wrapped in LRUCache to do automatic expiration. To prevent automatic expiration, Jinja overrides it to {}: You just set the environment to negative cache_size=-1 setting seen here and here

Environment settings for max performance:

• auto_reload=False will prevent Jinja from checking timestamps on-disk if the template is already in the cache.
• cache_size=-1 will prevent Jinja from purging the cache. Safe if you have a set number of templates, otherwise a static value such as cache_size=10000 would be plenty; the Jinja default is 400.

With these set, I do also believe the benefit of async would be limited to the initial load of the template.

May be a wise move to see these options noted in the deployment documentation @tomchristie because:

1. Templates have (almost) no opportunity to block when auto_reload=False.
2. This is what happens when you exceed cache_size: https://blog.socratic.org/the-one-weird-trick-that-cut-our-flask-page-load-time-by-70-87145335f679