Skip to content
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

Cache tiles as they are created #65

Open
apollolm opened this issue Oct 13, 2013 · 3 comments
Open

Cache tiles as they are created #65

apollolm opened this issue Oct 13, 2013 · 3 comments

Comments

@apollolm
Copy link

It would be awesome if tiles were only created once. Subsequent requests would just load the already-created tile. Maybe this is already happening, but it looks to me as if they're being created on every request.

@bensheldon
Copy link
Member

That's a good suggestion that we should probably discuss more. I think the primary intent of nodetiles is to provide a fast and flexible rendering back-end for highly dynamic data---as compared to say, pre-rendering a tilestache. We're also trying to run on ephemeral-ish platforms like Heroku, which makes caching something that would either have to be pretty distant (s3) or store in something like memcached or redis.

... that latter option of memcaching tiles actually would be relatively easy and (assuming that there are updated_at or similar timestamps on the data) have a relatively known way for invalidations.

Please let me know if you have any suggestions on where in the data/pre-rendering pipeline to allow for forking between a cached tile or rendered one. Otherwise I'll mull this over some more. Thanks for the suggestion!

@apollolm
Copy link
Author

Yeah - I think the memcaching would be cool. They could have a short time-to-live, but it should be long enough that if I zoom in a level and then zoom out, it should pull up the already-created tile. (Or better yet, let it be a variable that could be set).

@bensheldon
Copy link
Member

I think a possible design would be to implement an explicit middleware stack for sending the request and data down to the renderer, and for the image response back up from renderer to the client. Then we could insert a cache_read in the former and a cache_write in the latter. And leave the actual invalidation logic to the integrator (you!).

I'll talk to @Mr0grog about it since we haven't touched this project in too long.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants