-
Notifications
You must be signed in to change notification settings - Fork 67
Permit caching of COVIDcast signals for a few hours #159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
could be done in the .htaccess or via setting the header in the PHP file. e.g. https://www.askapache.com/hacking/speed-site-caching-cache-control/ |
Just added that to #171. It should also improve responsiveness when switching back and forth between signals on the map. |
I wasn't able to enable caching yet; I think |
what is the status here? if you don't have access to the webserver setting the value via PHP would be an option as in
or so |
I think that's feasible. To do it through Apache would require coordinating some configuration changes with Brian, testing those on staging, and so on, but I guess the question is how long we'd like to cache responses. Probably no more than a few hours, since signals update daily and someone who comes just before the update shouldn't have to wait 24 hours to get it? |
you roughly know when you put in new data each day. So you could just set the |
Each signal pipeline delivers data on a different schedule, though, so we'd have to build that into the code -- some kind of configuration file specifying expected delivery times for each pipeline. And then we'd have to think about what happens when a pipeline is late and how the headers should work. I think a simple first pass would just use a default short expiry, and we can go from there. |
...yeah I think we just set the expiry to the max expected visit length. I
don't think we expect someone to be continuously browsing the map for more
than an hour. It's okay if the first request of their next visit takes a
touch longer to load.
…On Wed, Sep 30, 2020 at 8:56 AM Alex Reinhart ***@***.***> wrote:
Each signal pipeline delivers data on a different schedule, though, so
we'd have to build that into the code -- some kind of configuration file
specifying expected delivery times for each pipeline. And then we'd have to
think about what happens when a pipeline is late and how the headers should
work.
I think a simple first pass would just use a default short expiry, and we
can go from there.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#159 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAI24CQHBI4DRPARQ5WDSFLSIMTJPANCNFSM4PGCQGAA>
.
|
There's probably a way to do this in Flask, but it looks like we don't yet? Here's what I get:
ie we say it's okay for a request to include a Cache-Control header but we don't send one in the response. |
related: caching headers for metadata |
None of the signals update more than once a day, so we could get a substantial performance boost in the map if we allowed caches to stay good for a few hours.
The text was updated successfully, but these errors were encountered: