4 ms·

All I read was "why we're okay with it being slow". EDIT: This is also not really a Rails issue per se, but maybe architectural.

andrewmutz 4y ago
Rails being slow is usually not something that the user can perceive. Instead, it's just something that increases your operating costs (more servers). For most online businesses, the operating cost of servers is small relative to the costs of support, sales, marketing and R&D. So, yes rails is slower, but it usually isn't slow in a way that is much of a negative for the business.
- stevebmark 4y ago
  Rails costs 2-3x more $ than other servers because of its poor performance. I think this is a significant tradeoff to make, as well as trading developer familiarity with the hardest and most dangerous software to upgrade and refactor. Maybe for Gitlab, which is a relatively small and straightforward piece of software with limited surface area, the sting won't be quite as strong.
  - andrewmutz 4y ago
    I agree rails costs 2-3x on servers, I just think that tends to not matter in a business context because those costs are small relative to everything else. What really moves the needle is R&D effectiveness. If your servers cost 2x with rails but your devs also produce 2x, that is a trade that is a good one for many businesses (especially startups and saas companies)
  - ericb 4y ago
    > Rails costs 2-3x more $ than other servers because of its poor performance. That's just not true. The vast majority of time for most web apps is spent in database calls. A typical runner up on time spent is remote system calls, which, if you accept the monolith tenet that maybe you don't need those, are minimised in a Rails app. If your app does anything meaningful, typically, that "meaningful stuff" so massively dwarfs the part of the time "in Rails" that worrying about the framework time is optimizing the wrong order of magnitude. I base this claim on looking at multiple real-world Java, Node, and Rails apps in New Relic, and during performance testing. Hint: the rails app outperformed both. Oh, wait--do you mean server costs? If you are talking about 2-3x more in servers, perhaps. Have you compared dev salaries to server costs, though? Here again, you'd be optimizing a small cost when you should be optimizing the big costs that matter.
    - stevebmark 4y ago
      > The vast majority of time for most web apps is spent in database calls. Which is why I wouldn't reach for a webserver that can only handle one request at a time per process
      - andrewmutz 4y ago
        Rails can use either threads or processes for parallelism.
        stevebmark 4y ago
        Sure, and Gitlab doesn't, because it's not practical
        andrewmutz 4y ago
        Why isn't it practical?
        ericb 4y ago
        Well, I developed and now manage dev for a Rails app that has half a million customers, with holiday demand peak times, etc. I haven't lost a night's sleep in the almost 10 years to the app. I'm interested in what impracticalities are involved in our threaded deployment of Rails?
        stevebmark 4y ago
        How do you get Rails models querying the db to use threads and not block the whole process from accepting other requests?
        ericb 4y ago
        Take a look into the ActiveRecord connection pool: https://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/ConnectionPool.html https://api.rubyonrails.org/classes/ActiveRecord/ConnectionA...
- dijit 4y ago
  > Rails being slow is usually not something that the user can perceive. It’s good that you used the word “usually”, w.r.t Gitlab it definitely feels slow. It’s not just a cost problem.
- Scarbutt 4y ago
  If Rails performance problems can be fixed with money (more servers) then why does everyone complains about gitlab being slow?
eximius 4y ago
In my experience, it's systemic in rails applications due to how many ways you have to shoot yourself in the foot - it "just works" but not in a good way. "Oh, this route takes 6 seconds to load. Why is that? OH, because it's making ten thousand database calls."

andrewmutz 4y ago

Rails being slow is usually not something that the user can perceive. Instead, it's just something that increases your operating costs (more servers). For most online businesses, the operating cost of servers is small relative to the costs of support, sales, marketing and R&D. So, yes rails is slower, but it usually isn't slow in a way that is much of a negative for the business.

stevebmark 4y ago
Rails costs 2-3x more $ than other servers because of its poor performance. I think this is a significant tradeoff to make, as well as trading developer familiarity with the hardest and most dangerous software to upgrade and refactor. Maybe for Gitlab, which is a relatively small and straightforward piece of software with limited surface area, the sting won't be quite as strong.
- andrewmutz 4y ago
  I agree rails costs 2-3x on servers, I just think that tends to not matter in a business context because those costs are small relative to everything else. What really moves the needle is R&D effectiveness. If your servers cost 2x with rails but your devs also produce 2x, that is a trade that is a good one for many businesses (especially startups and saas companies)
- ericb 4y ago
  > Rails costs 2-3x more $ than other servers because of its poor performance. That's just not true. The vast majority of time for most web apps is spent in database calls. A typical runner up on time spent is remote system calls, which, if you accept the monolith tenet that maybe you don't need those, are minimised in a Rails app. If your app does anything meaningful, typically, that "meaningful stuff" so massively dwarfs the part of the time "in Rails" that worrying about the framework time is optimizing the wrong order of magnitude. I base this claim on looking at multiple real-world Java, Node, and Rails apps in New Relic, and during performance testing. Hint: the rails app outperformed both. Oh, wait--do you mean server costs? If you are talking about 2-3x more in servers, perhaps. Have you compared dev salaries to server costs, though? Here again, you'd be optimizing a small cost when you should be optimizing the big costs that matter.
  - stevebmark 4y ago
    > The vast majority of time for most web apps is spent in database calls. Which is why I wouldn't reach for a webserver that can only handle one request at a time per process
    - andrewmutz 4y ago
      Rails can use either threads or processes for parallelism.
      - stevebmark 4y ago
        Sure, and Gitlab doesn't, because it's not practical
        andrewmutz 4y ago
        Why isn't it practical?
        ericb 4y ago
        Well, I developed and now manage dev for a Rails app that has half a million customers, with holiday demand peak times, etc. I haven't lost a night's sleep in the almost 10 years to the app. I'm interested in what impracticalities are involved in our threaded deployment of Rails?
        stevebmark 4y ago
        How do you get Rails models querying the db to use threads and not block the whole process from accepting other requests?
        ericb 4y ago
        Take a look into the ActiveRecord connection pool: https://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/ConnectionPool.html https://api.rubyonrails.org/classes/ActiveRecord/ConnectionA...
dijit 4y ago
> Rails being slow is usually not something that the user can perceive. It’s good that you used the word “usually”, w.r.t Gitlab it definitely feels slow. It’s not just a cost problem.
Scarbutt 4y ago
If Rails performance problems can be fixed with money (more servers) then why does everyone complains about gitlab being slow?

eximius 4y ago

In my experience, it's systemic in rails applications due to how many ways you have to shoot yourself in the foot - it "just works" but not in a good way. "Oh, this route takes 6 seconds to load. Why is that? OH, because it's making ten thousand database calls."