pillaiindu
What are the caching strategies in Phoenix?
In django there is a cache framework backed by memcached. Rails also puts a lot of emphasis on caching, and even the idea of russian-doll chaching comes from Rails community.
Elixir/Phoenix programmers often say that we don’t need caching at all in maximum of cases, because BEAM is faster than Python or Ruby. But there might be some point where we’d need to cache things. Where is that point? And when we reach the point when we need caching, what are the caching strategies and mechanisms then?
Thank You!
Most Liked
sasajuric
Indeed. Cachex is much more actively maintained as well as more feature rich, so that’s what I’d recommend first.
ConCache happened organically. I needed it for production with exactly those features, and it is a third incarnation of the caching library (the first two were close sourced), applying the lessons learned from the previous attempts. It behaved very well for that scenario. I didn’t have a need for such caching since that project (which I left 4 years ago), so due to the lack of real needs and the lack of spare time, ConCache hasn’t progressed since then, save for an occasional contribution.
ConCache is currently not abandoned, although I wonder whether we need two caching solutions in the Elixir community. At first glance, it seems that there’s a lot of overlap between these two libraries. When I find the time I’ll study cachex in more details, and see if it makes sense to decommission ConCache in favour of cachex. In case anyone else has already compared the two, I’d be happy to hear your thoughts.
brightball
The main reason that you hear that is because of how efficient templating is with Phoenix. In Rails for example, when you break down the response time on a page a HUUUUUGE portion of it is spent rendering the view layer.
The other issue is the cost per response for the web server. When you’re working with a server that can’t handle a high volume of concurrent connections, you create a situation where you have to focus on getting in and out as fast as possible.
Elixir and Phoenix address both of these. Cost per connection is almost nothing because of the BEAM and the view layer is compiled into IO Lists.
The short explanation IO Lists of why that is that all of the strings that make up your template code are immutable values in a linked list. Rather than constructing a full string based response, this list is sent back to the socket and iterated over directly. The full page response doesn’t ever exist on the server because the pieces are sent individually to the socket, meaning all of the memory allocation from creating and destroying each part of the template on every request never happens.
Here’s the long explanation though: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2-io-lists-in-phoenix/
For the volume of connections, even if you have a particularly slow database request, since the server can handle so many connections that one slow page isn’t going to degrade the experience of the others. If that particular page was dealing with a high volume of requests itself, it would be another story though.
The combination of these two means that the qualities that might normally cause a slow down that make you reach for different styles of caching are less necessary. The more you’re able to avoid caching the more you’re able to avoid cache invalidation, which gets to be more complicated as it grows.
If you do need caching, CacheEx is a very solid library that will let you wrap ETS and as a perk if you make 50 requests at the same time for the same piece of un-cached data, it will only make the request once and send the response back to all 50 requestors when it’s ready.
outlog
They can certainly become a bottleneck compared to ETS.. just going of the caching tangent..
btw, seems like Saša recommends checking out cachex first:
Popular in Discussions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance









