4 ms·

Didn't DHH write this post a few years ago about how layers of caching were needed to get Basecamp to perform at an acceptable speed? https://signalvnoise.com/

by gizmo 10y ago

Didn't DHH write this post a few years ago about how layers of caching were needed to get Basecamp to perform at an acceptable speed? https://signalvnoise.com/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui https://signalvnoise.com/posts/3112-how-basecamp-next-got-to... Computers are amazingly fast these days, but 99% of all CPU cycles go to waste because of this "slow is fast enough" mentality.

dmix 10y ago
> but 99% of all CPU cycles go to waste Reminds me of this tweet which summarizes Ruby quite well: https://twitter.com/reubenbond/status/662061791497744384 https://twitter.com/reubenbond/status/662061791497744384 There's no doubt that by not fully utilizing modern CPUs it is giving a serious advantage to the future prospects of languages like Elixir which make using concurrency as easy as using Rails or Go, where performance is baked-in. It's not so much about is Ruby good enough but why use Ruby in the long run if there are languages offering similar benefits but with better performance or good concurrency primitives? Having support for the latter is not a detriment to early stage projects using the languages (this isn't about Java/C++ vs Ruby any more...), but later on lacking it will
- Buetol 10y ago
  In reality you run your site on multiple workers and they share the CPUs.
davidw 10y ago
The problem for most startups is that they're not even sure that the CPU is spending its cycles on the right thing. A language/framework that helps you figure that out faster is superior to one that is slower to code with. And Ruby/Rails are pretty good from this point of view. I'll add: perhaps the time will come when there's something that's equally adept at being light on its feet, and is also faster. Elixir/Phoenix look interesting from that point of view. But even there... Erlang is certainly not the fastest thing out there.
dabeeeenster 10y ago
You would need caching regardless of the language. 99% of cache calls for web sites serve to offset the delay waiting for database calls to return, as opposed to any slowness with the programming language.
sethd 10y ago
Web applications are not CPU-bound, they're IO-bound. So in this scenario caching is used to reduce the amount of requests to the database. This can speed requests up but more importantly it allows you to more easily scale out horizontally.
- chrisseaton 10y ago
  > Web applications are not CPU-bound, they're IO-bound. Is that a fact? I'm not sure anyone has ever shown numbers to back it up. It would be an interesting piece of work to do. I can imagine it's true, but I'm not certain. I think Rap Genius did a blog post ages ago about being hosted on Heroku, and they said that something like 70% of time was spent inside the Ruby interpreter, not waiting on IO. So modest improvements in the speed of Ruby will have an impact on their bottom line.
  - sethd 10y ago
    I shouldn't have spoken in absolute terms, "primarily IO-bound" would have been a better choice of words. That said, in my experience this has been the case when it comes to handling HTTP requests.
  - twic 10y ago
    I take a bit of a No True Scotsman position on this. In general, web applications don't need to be CPU-bound: the amount of computation they need to do has a small cost compared to that of the IO they need to do. But not all web applications only do the computation they need to do - some do a lot of unnecessary computation. For example, there's a painfully slow web application at my company that puts data on a page by doing a straightforward select from a database, and then running lots of nested loops over the data to render the page. It's definitely CPU-bound. If it was written to use a more powerful query, or to use more sophisticated algorithms, it would be a lot faster, and would probably be IO-bound. But it isn't.
  - vidarh 10y ago
    It varies a lot depending on type of app. Backend dashboard full of reports? Odds are it will be waiting on complex JOIN's to complete in database requests. More lightweight stuff with mostly simple key'd queries and things like complex views can easily make it CPU bound. In general it's a useful idea that you're likely to be IO bound, because most of the time when something in a new webapp is too slow, it will be database (it may be a small fraction of overall requests, but the ones that hurt) until you have optimized/cached away your database request and are trying to scale further. Basically once you've solved the "naive"/early database bottleneck, then CPU and memory very quickly becomes more likely to be a cost factor.

by gizmo 10y ago

dmix 10y ago

> but 99% of all CPU cycles go to waste Reminds me of this tweet which summarizes Ruby quite well: https://twitter.com/reubenbond/status/662061791497744384 https://twitter.com/reubenbond/status/662061791497744384 There's no doubt that by not fully utilizing modern CPUs it is giving a serious advantage to the future prospects of languages like Elixir which make using concurrency as easy as using Rails or Go, where performance is baked-in. It's not so much about is Ruby good enough but why use Ruby in the long run if there are languages offering similar benefits but with better performance or good concurrency primitives? Having support for the latter is not a detriment to early stage projects using the languages (this isn't about Java/C++ vs Ruby any more...), but later on lacking it will

Buetol 10y ago
In reality you run your site on multiple workers and they share the CPUs.

davidw 10y ago

The problem for most startups is that they're not even sure that the CPU is spending its cycles on the right thing. A language/framework that helps you figure that out faster is superior to one that is slower to code with. And Ruby/Rails are pretty good from this point of view. I'll add: perhaps the time will come when there's something that's equally adept at being light on its feet, and is also faster. Elixir/Phoenix look interesting from that point of view. But even there... Erlang is certainly not the fastest thing out there.

dabeeeenster 10y ago

You would need caching regardless of the language. 99% of cache calls for web sites serve to offset the delay waiting for database calls to return, as opposed to any slowness with the programming language.

sethd 10y ago

Web applications are not CPU-bound, they're IO-bound. So in this scenario caching is used to reduce the amount of requests to the database. This can speed requests up but more importantly it allows you to more easily scale out horizontally.

chrisseaton 10y ago
> Web applications are not CPU-bound, they're IO-bound. Is that a fact? I'm not sure anyone has ever shown numbers to back it up. It would be an interesting piece of work to do. I can imagine it's true, but I'm not certain. I think Rap Genius did a blog post ages ago about being hosted on Heroku, and they said that something like 70% of time was spent inside the Ruby interpreter, not waiting on IO. So modest improvements in the speed of Ruby will have an impact on their bottom line.
- sethd 10y ago
  I shouldn't have spoken in absolute terms, "primarily IO-bound" would have been a better choice of words. That said, in my experience this has been the case when it comes to handling HTTP requests.
- twic 10y ago
  I take a bit of a No True Scotsman position on this. In general, web applications don't need to be CPU-bound: the amount of computation they need to do has a small cost compared to that of the IO they need to do. But not all web applications only do the computation they need to do - some do a lot of unnecessary computation. For example, there's a painfully slow web application at my company that puts data on a page by doing a straightforward select from a database, and then running lots of nested loops over the data to render the page. It's definitely CPU-bound. If it was written to use a more powerful query, or to use more sophisticated algorithms, it would be a lot faster, and would probably be IO-bound. But it isn't.
- vidarh 10y ago
  It varies a lot depending on type of app. Backend dashboard full of reports? Odds are it will be waiting on complex JOIN's to complete in database requests. More lightweight stuff with mostly simple key'd queries and things like complex views can easily make it CPU bound. In general it's a useful idea that you're likely to be IO bound, because most of the time when something in a new webapp is too slow, it will be database (it may be a small fraction of overall requests, but the ones that hurt) until you have optimized/cached away your database request and are trying to scale further. Basically once you've solved the "naive"/early database bottleneck, then CPU and memory very quickly becomes more likely to be a cost factor.