OutputCaching

[bigpilot]

I already made an Issue for this, but couldn't find how to flag it as a "Suggestion" but is OutputCaching currently available in Rocket?

I mean, why focus on speeding up the page generation when you don't need to. This is especially useful on high-traffic websites where most of the pages can be retrieved from the cache.

For example: let's say you have a mostly static page with the time on it, which is obviously generated by some code. But the server only needs to generate a new page every second (the time displayed only shows hours:minutes:seconds) and this could have a huge impact if thousands of users are hitting your site. If a thousand users are hitting your site every second 999 of them will get the page from the cache!

[edgarogh]

As far as I know, rocket doesn't natively support caching HTTP responses. However, depending on your use case, you could use a reverse proxy (if most of your website would benefit from caching, this may be a good idea), or do the job "yourself".

The cached crate can probably work for most cases. Example here :

#[macro_use]
extern crate rocket;

use std::time::Duration;
use cached::{proc_macro::cached, TimedCache};

#[rocket::launch]
fn launch() -> _ {
    rocket::build()
        .mount("/", routes![long_to_compute])
}

#[get("/")]
#[cached(
    type = "TimedCache<(), &'static str>",
    create = "{ TimedCache::with_lifespan(100) }",
)]
fn long_to_compute() -> &'static str {
    std::thread::sleep(Duration::from_secs(2));
    "Long calculation is done"
}

It supports various kinds of caches, works with async functions, and you can obviously have the parameters of the cached function (here, it would be the various FromRequest/FromData/FromParam of your route) act as a key to a cache entry.

Of course, Rocket will still have to write the HTTP headers for every response, but if your handler does a database call for instance, the gain will still be noticeable.

[the10thWiz]

The only note is that the example shouldn't use std::thread::sleep, but rather the sleep function exposed by tokio (and await on it), since otherwise it might block the main threads. It would also clearly demonstrate the ability of cached to work on async functions.

[edgarogh]

@the10thWiz That's a bad suggestion, the original question mentions a CPU-bound task, and std::thread::sleep is the best way to model that in a simple way.

Tokio's sleep doesn't block anything actually, it just suspends the task and schedules a wake up at a specific time. The example would "work" but it would be overly complicated (it involves another crate, tokio) and it wouldn't simulate a real-world CPU-bound situation as good as std::thread::sleep does.

[the10thWiz]

In that case, it should be wrapped in a spawn_blocking call, to avoid blocking the tokio scheduler.

[edgarogh]

Please re-read the original question. The goal is just to render a template and cache it so the page can be served a few thousand times per second without re-running the template engine. Rendering a template engine is certainly a CPU-bound task, but spawning a new thread/task just for this is utterly ridiculous.

Of course, if you're doing, say, password hashing, you will have to use spawn_blocking so tokio isn't blocked. But rendering a template shouldn't take more than a millisecond (on a bad computer). Spawning a task for that is nonsensical.