4 ms·

> The ?good? news though is that Heroku is really slow Did you do any measurements and if so, on which dyno types? We found that using Performance-M dynos' giv

> The ?good? news though is that Heroku is really slow Did you do any measurements and if so, on which dyno types? We found that using Performance-M dynos' gives us a rather large performance boost. Performance-m dyno's are also more stable because they run on dedicatd hardware. They're expensive, but we don't run any apps in production without it. One thing that worked really well for us is to just put Cloudflare or Cloudfront in front of our app. As I mentioned, we don't do any full-page caching. We cache pretty much everything else, but pages themselves have zero caching (business requirement). I believe Cloudflare and Cloudfront also do edge TLS. > Read replicas are a good idea, we'd actually like to try that out at some point. It seems pretty doable to put something like pgbounce/pgpool in front of a read replica and let it handle routing write transactions properly. This is going to be tricky. We weren't able to set up replication from Heroku Postgres databases to hosts outside of Heroku. Another thing to keep in mind that is it might be better to let the app decide what is a read query and what is a write query. We have some parts of the app that we need reading directly from the master, so we let the app handle it. The app receives two database URI's, both pointing to pgbouncer.

sudhirj 7y ago
I tried adding Cloudfront in front of an app hosted on Heroku with page caching off (Vary by Cookie) and it increased latency to 3X, never could figure out why. Would like to do it but seems like way too much of a trade off.
- mrkurt 7y ago
  Shameless plug, https://fly.io/heroku https://fly.io/heroku gives you a lot of the benefit of Cloudfront without adding a layer. It's like running Heroku with a modern router. --edit-- I confused Cloudfront and CloudFlare yet again. :)
  - sudhirj 7y ago
    Yeah, I’m gonna try this out. I’m writing a book authoring platform and I want to let people give access to their books on their own domains. Is there an API to add custom domains with LE certs to my app? And is there a limit on how many domains I can add?
    - mrkurt 7y ago
      There is indeed a certificate API! We’re putting up a guide for it this week, I can send you the draft if you’d like. The CLI commands for managing certs are here: https://fly.io/docs/flyctl/certs/ https://fly.io/docs/flyctl/certs/ There’s no limit to domains.
mrkurt 7y ago
> Did you do any measurements and if so, on which dyno types? We found that using Performance-M dynos' gives us a rather large performance boost. Performance-m dyno's are also more stable because they run on dedicatd hardware. They're expensive, but we don't run any apps in production without it. We did some measurements, but mostly focusing on the network bits (which you largely solved with CloudFlare): https://fly.io/blog/turboku/ https://fly.io/blog/turboku/ I was surprised at how much faster things seemed on our VMs vs Heroku's Dynos, to be honest. We only compared Standard dynos, but we should be even better price vs performance compared to the performance dynos since we run our own physical servers. A performance-m dyno on Heroku costs about the same as 8 cpus on fly. It's totally self serving, but if you feel like playing around with the Fly stuff I'd love to know how it compares. > This is going to be tricky. We weren't able to set up replication from Heroku Postgres databases to hosts outside of Heroku. Another thing to keep in mind that is it might be better to let the app decide what is a read query and what is a write query. We have some parts of the app that we need reading directly from the master, so we let the app handle it. The app receives two database URI's, both pointing to pgbouncer. This is why I think the in memory caching is such a good option. Usually if I'm building an app, I'll add a caching layer before a DB replica. Write through caching seems to fit my mental processes better. :D
manigandham 7y ago
Cloudflare and Fly are both reverse-proxy CDN services that handle caching and TLS at the edge. They also both support running arbitrary logic at the edge. Cloudflare has Workers (javascript web workers API) with their custom KV key/value persistent data layer. Fly started similar but now supports containers running anything and has a Redis non-persistent cache layer. If all you're doing is caching some endpoints and TLS termination then either will work. Cloudflare has a bigger network with robust security capabilities, Fly has more flexibility in application logic you can run. Data has gravity and having a globally distributed database layer is something companies have spent millions on. Usually the solution is to cache as much as possible in each region first, then look at doing database replicas, and eventually multi-regional active/active database scale-outs.

sudhirj 7y ago

I tried adding Cloudfront in front of an app hosted on Heroku with page caching off (Vary by Cookie) and it increased latency to 3X, never could figure out why. Would like to do it but seems like way too much of a trade off.

mrkurt 7y ago
Shameless plug, https://fly.io/heroku https://fly.io/heroku gives you a lot of the benefit of Cloudfront without adding a layer. It's like running Heroku with a modern router. --edit-- I confused Cloudfront and CloudFlare yet again. :)
- sudhirj 7y ago
  Yeah, I’m gonna try this out. I’m writing a book authoring platform and I want to let people give access to their books on their own domains. Is there an API to add custom domains with LE certs to my app? And is there a limit on how many domains I can add?
  - mrkurt 7y ago
    There is indeed a certificate API! We’re putting up a guide for it this week, I can send you the draft if you’d like. The CLI commands for managing certs are here: https://fly.io/docs/flyctl/certs/ https://fly.io/docs/flyctl/certs/ There’s no limit to domains.

mrkurt 7y ago

> Did you do any measurements and if so, on which dyno types? We found that using Performance-M dynos' gives us a rather large performance boost. Performance-m dyno's are also more stable because they run on dedicatd hardware. They're expensive, but we don't run any apps in production without it. We did some measurements, but mostly focusing on the network bits (which you largely solved with CloudFlare): https://fly.io/blog/turboku/ https://fly.io/blog/turboku/ I was surprised at how much faster things seemed on our VMs vs Heroku's Dynos, to be honest. We only compared Standard dynos, but we should be even better price vs performance compared to the performance dynos since we run our own physical servers. A performance-m dyno on Heroku costs about the same as 8 cpus on fly. It's totally self serving, but if you feel like playing around with the Fly stuff I'd love to know how it compares. > This is going to be tricky. We weren't able to set up replication from Heroku Postgres databases to hosts outside of Heroku. Another thing to keep in mind that is it might be better to let the app decide what is a read query and what is a write query. We have some parts of the app that we need reading directly from the master, so we let the app handle it. The app receives two database URI's, both pointing to pgbouncer. This is why I think the in memory caching is such a good option. Usually if I'm building an app, I'll add a caching layer before a DB replica. Write through caching seems to fit my mental processes better. :D

manigandham 7y ago

Cloudflare and Fly are both reverse-proxy CDN services that handle caching and TLS at the edge. They also both support running arbitrary logic at the edge. Cloudflare has Workers (javascript web workers API) with their custom KV key/value persistent data layer. Fly started similar but now supports containers running anything and has a Redis non-persistent cache layer. If all you're doing is caching some endpoints and TLS termination then either will work. Cloudflare has a bigger network with robust security capabilities, Fly has more flexibility in application logic you can run. Data has gravity and having a globally distributed database layer is something companies have spent millions on. Usually the solution is to cache as much as possible in each region first, then look at doing database replicas, and eventually multi-regional active/active database scale-outs.