4 ms·

Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinve

by nthj 6y ago

Web apps are usually slow because of (1) poor data modeling/unoptimized SQL/unindexed tables, (2) ad tracker bloat, and (3) single page applications that reinvent the DOM for $reasons. Swapping out ruby for golang won’t fix any of those. I’ve worked on multiple Rails apps over the past decade, responsible for hundreds of thousands of customers and hundreds of millions in revenue, that easily rendered every page in 150-300ms. This isn’t time-to-first-byte—this is fully rendered, images and all.

cercatrova 6y ago
However, fixing all of those, which costs less in server time (and potentially even dev time, debatable)? I've seen hundreds of Rust based sites on a single 5 dollar droplet while the same would take an order of magnitude more servers. At scale, this gets expensive. See Stripe, Shopify etc that have found this out.
- kyledrake 6y ago
  I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached. If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.
  - cercatrova 6y ago
    We can do both, I never said one should be prioritized over the other.
    - ryanbrunner 6y ago
      One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient. It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles. You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.
- nthj 6y ago
  To try to clarify: none of my 3 points above are fixed by rust, golang, or any other language, because they are not caused by Rails. Uncharitably, in my experience, these 3 bottlenecks are usually accidental consequences of decisions made by software developers who do not fully understand the whole lifecycle of a web application request/response. I usually run Rails on two servers for redundancy. Any features that are CPU expensive I will spin off into a separate service (I’m partial to golang.) This is all on the order of $10s of dollars a month on AWS. 90% of most products’ landscapes are CRUD, and bottlenecked on IO to the database, not expensive CPU calculations. Stripe primarily interfaces with 3rd party payment systems. Anytime a request has dependencies outside of the database, you’re “off the Rails” and should investigate additional options. Shopify is a great example. Last I checked, Shopify is doing great still using Rails for 90% of CRUD and are optimizing just the 10% that they see ROI from.
  - cercatrova 6y ago
    That's fine, I never said everything is solved by switching languages. But oftentimes focus in performance in one area, ie language choice, is correlated with performances concerns over other parts of the app.

by nthj 6y ago

cercatrova 6y ago

However, fixing all of those, which costs less in server time (and potentially even dev time, debatable)? I've seen hundreds of Rust based sites on a single 5 dollar droplet while the same would take an order of magnitude more servers. At scale, this gets expensive. See Stripe, Shopify etc that have found this out.

kyledrake 6y ago
I run a busy production ruby app on a $40/month droplet. My performance issues are almost never related to ruby. It's nearly 100% of the time some complex database query that needs to get indexed/cached. If coders write their backend in rust for "the ultimate performance", and it's shipping 20MB of javascript to query a poorly designed, poorly indexed database with no caching, they're going to get far worse performance than a ruby app querying a properly designed, cached database with indexing that doesn't have to spend 5 seconds domming the user's DOM first. Performance is a holistic problem, and anecdotally, web sites felt a lot faster during the rails era than they do right now during the JS era.
- cercatrova 6y ago
  We can do both, I never said one should be prioritized over the other.
  - ryanbrunner 6y ago
    One abosolutely should be prioritized over the other. There's never going to be a situation where you can address every potential source of slowdowns, and make everything 100% efficient all of the time. Given that, in any somewhat realistic environment, you're going to need to prioritize where to spend your focus on making things more efficient. It's certainly possible that the answer is that the language you're using is fundamentally too slow - I personally have almost never experienced that - almost always I can get more out of a time investment by focusing on improving DB performance, or some problem with delivery, caching or optimizing bundles. You should look at your personal situation and use real data to decide where to focus, but you always have to focus. "Make everything 100% efficient at all times" is completely unrealistic.
nthj 6y ago
To try to clarify: none of my 3 points above are fixed by rust, golang, or any other language, because they are not caused by Rails. Uncharitably, in my experience, these 3 bottlenecks are usually accidental consequences of decisions made by software developers who do not fully understand the whole lifecycle of a web application request/response. I usually run Rails on two servers for redundancy. Any features that are CPU expensive I will spin off into a separate service (I’m partial to golang.) This is all on the order of $10s of dollars a month on AWS. 90% of most products’ landscapes are CRUD, and bottlenecked on IO to the database, not expensive CPU calculations. Stripe primarily interfaces with 3rd party payment systems. Anytime a request has dependencies outside of the database, you’re “off the Rails” and should investigate additional options. Shopify is a great example. Last I checked, Shopify is doing great still using Rails for 90% of CRUD and are optimizing just the 10% that they see ROI from.
- cercatrova 6y ago
  That's fine, I never said everything is solved by switching languages. But oftentimes focus in performance in one area, ie language choice, is correlated with performances concerns over other parts of the app.