47 ms·

> If 90% of the time in an application is spent in database calls This is what a lot of people say, but I'm not sure that this is the case. I think apps spend

> If 90% of the time in an application is spent in database calls This is what a lot of people say, but I'm not sure that this is the case. I think apps spend about 50-70% of their time in compute in the interpreter, at the low end. People don't often make metrics from their apps public, but here's one example from a web site that renders text - so it's reading from the database and not doing some unusually computational task with the result https://genius.com/James-somers-herokus-ugly-secret-annotated https://genius.com/James-somers-herokus-ugly-secret-annotate....

zasdffaa 4y ago
"if" It doesn't say they do.
suction 4y ago
As for anecdotal evidence seen in a consultancy function: You are wrong in assuming that companies always hire database experts or data scientists to write their db queries who know how to not make the db the bottleneck. In reality you'll find developers who claim "we can't use Ruby here because it's too slow!" while they're unaware that the reason their page needs seconds to load is because of hilariously inefficient queries to the db.
- jiggawatts 4y ago
  In my consulting experience, I'm shocked if I find that inefficient queries aren't the root cause of poor performance. In fact, thinking about it, I don't think it has ever happened. I always look at the DB layer first because it's virtually guaranteed that someone wrote a "SELECT * FROM MassiveTable" and added it to the common header code used by every page.
  - vidarh 4y ago
    Matches my experience too, both consulting and in-house as the person who'd be the first to even consider looking at the database query logs or running "explain" on queries. A reason for ORMs is that a lot of developers fear the database (EDIT: not the only reason, to be clear; I love and use ORMs). A result of ORMs is that a lot of developers think they can avoid understanding the database.
- rco8786 4y ago
  +1 to this. I've lead performance optimization on enough real-world problems to be conditioned to just go straight to the database access patterns from the start...it's always there. Modern languages, including Ruby, are all plenty fast enough computationally for the vast majority of business workloads that aren't Google scale. When things slow down...it's the database or something similar like N+1s calling external APIs.
  - brightball 4y ago
    Yep. Agree here entirely. You can even be tricked into looking at heavy write load due to temporary tables being created for huge reads. The more people seem to focus on mastering their language or framework, the more they seem to forget that there’s nothing more important than SQL.
- jasonwatkinspdx 4y ago
  I'm pretty sure the highest value per character code I've written so far was a 10 line monkey punch back in the rails 3 era that would crash the app if you tried to use an active record query without a limit or with too high a limit.
  - the_sleaze9 4y ago
    Hehehe, that reminds me of a similar active record monkey patch at an old job, the name of which was used as a swear word everywhere except where that particular engineer was present.
skunkworker 4y ago
I agree, optimizing db calls in my experience has been low hanging fruit. But (in rails) going through and making your own poro + active model objects can give significant speed increases, especially in cases where the Rails overhead is too high. Object instantiation and database serialization/deserialization seem to be a pain point that gets overlooked more than people realize. But in this case I’m preaching to the choir on ruby app optimization. Do you forsee projects like Rails needing to be rewritten in order to be more favorably JIT and interpreted by truffleruby & ruby jit?
- faebi 4y ago
  More than once I run into db serialization performance issues. Postgres reports all nice and fast, yet requests are slow. It took me a while to figure out that activerecord was busy converting my data into one large query string, and then busy sending that string over the wire. The issue was a field using postgres jsonb and I was filling in a large array of text lines in some cases. Workarounds are easy but I never pinned down why it would take multiple 100‘s of milliseconds to serialize into sql.
jillesvangurp 4y ago
I haven't seen too much ruby in the wild lately. Most of my customers use other stacks (python, go, php, jvm, etc.). I default to using Kotlin these days which gives me a nice compromise of an expressive language, nice frameworks, and excellent scaling abilities and performance. But I deal with whatever comes on my path. Mostly, throwing money at the problem and scaling horizontally is a perfectly acceptable solution and when it isn't, using ruby is probably not the way forward either and you might want to consider more performant stacks. That being said, unless you are doing very strange things, you should be able to make ruby perform acceptably. Something, I've observed in other people's ruby code is that it sucks you into doing sub optimal things. Rails and orm can lead people into doing things that just result in a lot of needless database traffic. That's not a ruby problem but just poor design. I've seen people get into trouble with java/hibernate as well. Solution: optimize your queries and database schema and think about what kind of indices you need. Another common issue is people doing silly things with parsing and processing the same things over and over again. Caching helps, good algorithms help, etc. This too is not really a language problem but a design issue. In terms of percentages, most ruby apps are single threaded and use blocking IO; which is why you fire up many ruby processes on a server. So, whenever it is dealing with IO, which should be most of the time, it shouldn't be using much CPU. That's why you can have many more ruby processes than cpu cores, most of those processes would be idling or blocked on IO most of the time (orders of magnitude slower than any computation). This is of course not a great use of memory and you are likely to exhaust that sooner than the cpu. If you can load test, you should be able to find the limit.
ryanbrunner 4y ago
I've worked with Ruby for 12 years and I've never once had Ruby itself be the cause of poor performance. It's almost without exception the database. It might be fair to say a well-optimized route spends 50-70% of it's time in the interpreter, but for non-optimized routes that's far too high.

zasdffaa 4y ago

"if" It doesn't say they do.

suction 4y ago

As for anecdotal evidence seen in a consultancy function: You are wrong in assuming that companies always hire database experts or data scientists to write their db queries who know how to not make the db the bottleneck. In reality you'll find developers who claim "we can't use Ruby here because it's too slow!" while they're unaware that the reason their page needs seconds to load is because of hilariously inefficient queries to the db.

jiggawatts 4y ago
In my consulting experience, I'm shocked if I find that inefficient queries aren't the root cause of poor performance. In fact, thinking about it, I don't think it has ever happened. I always look at the DB layer first because it's virtually guaranteed that someone wrote a "SELECT * FROM MassiveTable" and added it to the common header code used by every page.
- vidarh 4y ago
  Matches my experience too, both consulting and in-house as the person who'd be the first to even consider looking at the database query logs or running "explain" on queries. A reason for ORMs is that a lot of developers fear the database (EDIT: not the only reason, to be clear; I love and use ORMs). A result of ORMs is that a lot of developers think they can avoid understanding the database.
rco8786 4y ago
+1 to this. I've lead performance optimization on enough real-world problems to be conditioned to just go straight to the database access patterns from the start...it's always there. Modern languages, including Ruby, are all plenty fast enough computationally for the vast majority of business workloads that aren't Google scale. When things slow down...it's the database or something similar like N+1s calling external APIs.
- brightball 4y ago
  Yep. Agree here entirely. You can even be tricked into looking at heavy write load due to temporary tables being created for huge reads. The more people seem to focus on mastering their language or framework, the more they seem to forget that there’s nothing more important than SQL.
jasonwatkinspdx 4y ago
I'm pretty sure the highest value per character code I've written so far was a 10 line monkey punch back in the rails 3 era that would crash the app if you tried to use an active record query without a limit or with too high a limit.
- the_sleaze9 4y ago
  Hehehe, that reminds me of a similar active record monkey patch at an old job, the name of which was used as a swear word everywhere except where that particular engineer was present.

skunkworker 4y ago

I agree, optimizing db calls in my experience has been low hanging fruit. But (in rails) going through and making your own poro + active model objects can give significant speed increases, especially in cases where the Rails overhead is too high. Object instantiation and database serialization/deserialization seem to be a pain point that gets overlooked more than people realize. But in this case I’m preaching to the choir on ruby app optimization. Do you forsee projects like Rails needing to be rewritten in order to be more favorably JIT and interpreted by truffleruby & ruby jit?

faebi 4y ago
More than once I run into db serialization performance issues. Postgres reports all nice and fast, yet requests are slow. It took me a while to figure out that activerecord was busy converting my data into one large query string, and then busy sending that string over the wire. The issue was a field using postgres jsonb and I was filling in a large array of text lines in some cases. Workarounds are easy but I never pinned down why it would take multiple 100‘s of milliseconds to serialize into sql.

jillesvangurp 4y ago

I haven't seen too much ruby in the wild lately. Most of my customers use other stacks (python, go, php, jvm, etc.). I default to using Kotlin these days which gives me a nice compromise of an expressive language, nice frameworks, and excellent scaling abilities and performance. But I deal with whatever comes on my path. Mostly, throwing money at the problem and scaling horizontally is a perfectly acceptable solution and when it isn't, using ruby is probably not the way forward either and you might want to consider more performant stacks. That being said, unless you are doing very strange things, you should be able to make ruby perform acceptably. Something, I've observed in other people's ruby code is that it sucks you into doing sub optimal things. Rails and orm can lead people into doing things that just result in a lot of needless database traffic. That's not a ruby problem but just poor design. I've seen people get into trouble with java/hibernate as well. Solution: optimize your queries and database schema and think about what kind of indices you need. Another common issue is people doing silly things with parsing and processing the same things over and over again. Caching helps, good algorithms help, etc. This too is not really a language problem but a design issue. In terms of percentages, most ruby apps are single threaded and use blocking IO; which is why you fire up many ruby processes on a server. So, whenever it is dealing with IO, which should be most of the time, it shouldn't be using much CPU. That's why you can have many more ruby processes than cpu cores, most of those processes would be idling or blocked on IO most of the time (orders of magnitude slower than any computation). This is of course not a great use of memory and you are likely to exhaust that sooner than the cpu. If you can load test, you should be able to find the limit.

ryanbrunner 4y ago

I've worked with Ruby for 12 years and I've never once had Ruby itself be the cause of poor performance. It's almost without exception the database. It might be fair to say a well-optimized route spends 50-70% of it's time in the interpreter, but for non-optimized routes that's far too high.