4 ms·

There are an incredible number of websites that have incredible read:write ratios. I would suggest doing everything you can to avoid writing to the database on

There are an incredible number of websites that have incredible read:write ratios. I would suggest doing everything you can to avoid writing to the database on every request.

jrochkind1 5y ago
I wonder, of those websites with incredible read:write ratios, how many have the read-only requests pretty cacheable at CDN level.
- mrkurt 5y ago
  Not many. I worked on Ars Technica back in the day, it's the most CDN-like workload you can imagine. We couldn't ship features we thought were valuable, though, because the CDN was in the way. CDNs have gotten better, and you can write an app in JavaScript to sit in front of your Rails app to make things more dynamic if you want. I believe most devs are better off running their fullstack app where they need it and skipping the additional infrastructure layer. CDNs are an architectural misfeature that only exist because Fly.io wasn't around 20 years ago. I'm being extreme, but I think that's fundamentally true. ;)
  - pbowyer 5y ago
    > CDNs are an architectural misfeature that only exist because Fly.io wasn't around 20 years ago. I'm being extreme, but I think that's fundamentally true. ;) Spicy take :) Although building for a dynamic CDN (I'm thinking Varnish here) feels like building inside-out, I can't see a way to deliver pageviews as efficiently (in terms of CPU or Watts per view) without using a CDN and a lot of caching. With Fly I guess you flip the architecture around and run code but cache a lot of partials that you assemble together. Nicer than working with ESI and its "cache it all but punch holes in the page and render those bits again" approach, but does the efficiency hold up? My architectural misfeature would be ESI [1,2]. So useful and so painful to use. And that's before we get to varying support in different proxies and caches... 1. https://www.mnot.net/blog/2011/10/21/why_esi_is_still_important_and_how_to_make_it_better https://www.mnot.net/blog/2011/10/21/why_esi_is_still_import... 2. https://twitter.com/peterbowyer/status/1366324396026118149 https://twitter.com/peterbowyer/status/1366324396026118149
    - mrkurt 5y ago
      It is a spicy take. I agree that Varnish and commodity CDNs are more efficient per pageview than hitting any kind of full stack app process. Most devs can probably ignore efficiency, though. Making things fast for users will take them a long way. My spicy take is really "in the context of full stack apps". CDNs are amazing for, like, Netflix. And Wikipedia. They're really, really good for one to many files. With Fly, you do flip it around. And you might find out you don't really even need a cache. Rails + Postgres read replicas are pretty dang fast with one less moving piece. We have an awful lot of users who just do in process caching and hit their DB when they need to, it's pretty cool. ESI seemed so promising when I first read about it. Then I realized I couldn't actually _use_ it anywhere. I'm still kind of aggravated at how excited it made me.
      - jrochkind1 5y ago
        I am currently finding Rails view generation to be shockingly slow. (no DB query involved, just the view generation computation). I guess I do too many complicated things in my view generation. (But one thing I don't currently do that has always looked shockingly slow when I've measured it, is Rails i18n. But in general, I'm kind of surprised to find you saying Rails view generation is pretty dang fast! It's always seemed to me like the Rails answer was "yeah, we know, that's why you cache." But now I wonder what I'm doing terribly wrong...)
        mrkurt 5y ago
        Rails view generation is shockingly slow. I would definitely cache partials, I just wouldn't run Redis to do it if I could help it! Rails is basically the worst case framework for our model, so we were excited when we got it working. You still have to work hard to make Rails fast, we just give you the last mile for almost-free.
        jrochkind1 5y ago
        OK, phew, it's not just me! I guess I misinterpreted when you said "And you might find out you don't really even need a cache. Rails + Postgres read replicas are pretty dang fast." You actually meant, you might not need a CDN cache... if you have some other kind of cache (which btw ideally isn't redis if you're using our model anyway)... because Rails actually isn't pretty dang fast at all? OK then! :)
  - tshaddox 5y ago
    I agree that Ars Technica seems like a very CDN-friendly workload. I'm curious what those features were that you couldn't ship because of the CDN. It's gotta just be ads, right?
    - mrkurt 5y ago
      No, the opposite actually. When the ad market fell apart we launched a paid subscriber program. It immediately turned us into an app that cared about a smaller number of high value users. Almost everything we wanted to add was for those folks - personalization and collaboration features, mostly. Ads have never been fun to build around.
barrkel 5y ago
There are good reasons to do it independent of simple ratio; for example, if you want the site to function as much as possible with a read-only database - not uncommon in recovery, failover or big migration situations.

There are an incredible number of websites that have incredible read:write ratios. I would suggest doing everything you can to avoid writing to the database on every request.

jrochkind1 5y ago

I wonder, of those websites with incredible read:write ratios, how many have the read-only requests pretty cacheable at CDN level.

mrkurt 5y ago
Not many. I worked on Ars Technica back in the day, it's the most CDN-like workload you can imagine. We couldn't ship features we thought were valuable, though, because the CDN was in the way. CDNs have gotten better, and you can write an app in JavaScript to sit in front of your Rails app to make things more dynamic if you want. I believe most devs are better off running their fullstack app where they need it and skipping the additional infrastructure layer. CDNs are an architectural misfeature that only exist because Fly.io wasn't around 20 years ago. I'm being extreme, but I think that's fundamentally true. ;)
- pbowyer 5y ago
  > CDNs are an architectural misfeature that only exist because Fly.io wasn't around 20 years ago. I'm being extreme, but I think that's fundamentally true. ;) Spicy take :) Although building for a dynamic CDN (I'm thinking Varnish here) feels like building inside-out, I can't see a way to deliver pageviews as efficiently (in terms of CPU or Watts per view) without using a CDN and a lot of caching. With Fly I guess you flip the architecture around and run code but cache a lot of partials that you assemble together. Nicer than working with ESI and its "cache it all but punch holes in the page and render those bits again" approach, but does the efficiency hold up? My architectural misfeature would be ESI [1,2]. So useful and so painful to use. And that's before we get to varying support in different proxies and caches... 1. https://www.mnot.net/blog/2011/10/21/why_esi_is_still_important_and_how_to_make_it_better https://www.mnot.net/blog/2011/10/21/why_esi_is_still_import... 2. https://twitter.com/peterbowyer/status/1366324396026118149 https://twitter.com/peterbowyer/status/1366324396026118149
  - mrkurt 5y ago
    It is a spicy take. I agree that Varnish and commodity CDNs are more efficient per pageview than hitting any kind of full stack app process. Most devs can probably ignore efficiency, though. Making things fast for users will take them a long way. My spicy take is really "in the context of full stack apps". CDNs are amazing for, like, Netflix. And Wikipedia. They're really, really good for one to many files. With Fly, you do flip it around. And you might find out you don't really even need a cache. Rails + Postgres read replicas are pretty dang fast with one less moving piece. We have an awful lot of users who just do in process caching and hit their DB when they need to, it's pretty cool. ESI seemed so promising when I first read about it. Then I realized I couldn't actually _use_ it anywhere. I'm still kind of aggravated at how excited it made me.
    - jrochkind1 5y ago
      I am currently finding Rails view generation to be shockingly slow. (no DB query involved, just the view generation computation). I guess I do too many complicated things in my view generation. (But one thing I don't currently do that has always looked shockingly slow when I've measured it, is Rails i18n. But in general, I'm kind of surprised to find you saying Rails view generation is pretty dang fast! It's always seemed to me like the Rails answer was "yeah, we know, that's why you cache." But now I wonder what I'm doing terribly wrong...)
      - mrkurt 5y ago
        Rails view generation is shockingly slow. I would definitely cache partials, I just wouldn't run Redis to do it if I could help it! Rails is basically the worst case framework for our model, so we were excited when we got it working. You still have to work hard to make Rails fast, we just give you the last mile for almost-free.
        jrochkind1 5y ago
        OK, phew, it's not just me! I guess I misinterpreted when you said "And you might find out you don't really even need a cache. Rails + Postgres read replicas are pretty dang fast." You actually meant, you might not need a CDN cache... if you have some other kind of cache (which btw ideally isn't redis if you're using our model anyway)... because Rails actually isn't pretty dang fast at all? OK then! :)
- tshaddox 5y ago
  I agree that Ars Technica seems like a very CDN-friendly workload. I'm curious what those features were that you couldn't ship because of the CDN. It's gotta just be ads, right?
  - mrkurt 5y ago
    No, the opposite actually. When the ad market fell apart we launched a paid subscriber program. It immediately turned us into an app that cared about a smaller number of high value users. Almost everything we wanted to add was for those folks - personalization and collaboration features, mostly. Ads have never been fun to build around.

barrkel 5y ago

There are good reasons to do it independent of simple ratio; for example, if you want the site to function as much as possible with a read-only database - not uncommon in recovery, failover or big migration situations.