Rails 5.0: Action Cable, API mode, and more • Hacker News Board

Re: Rails 5.0: Action Cable, API mode, and more

#211

Post by andrewstuart2 » Fri, Jul 01, 2016, 8:25 PM UTC

karmajunkie wrote: post #177

andrewstuart2 wrote: post #60

Earlier quoted context omitted.

It is, sometimes. But a cache hit in 50-150ns beats the pants off of a round trip to the backing database or microservice, which might take tens of milliseconds. That's 100,000-1,000,000x faster. It's the same reason you'd never find a modern CPU without multiple layers of caching.

That's not the kind of caching GP was referring to, at least not to my reading. I think you'd be hard pressed to find any application level caching that could serve up a cache in the nanosecond range. At best you're looking at sub millisecond range, and that's when the cache lives in memory on the same hardware. Application caching on any modern cloud provider is almost always going to be a network call and best case…

True, I was only citing the figure for memory access times on x86 (according to a quick google). There's certainly going to be more overhead depending on how the cache is implemented, whether it's in memory, or swapped out/deliberately on disk, etc.

That said, I'd call it a fundamental architecture requirement (and one you can't really avoid anyway), given fundamental limitations imposed by the speed of light.

Re: Rails 5.0: Action Cable, API mode, and more

#212

Post by alehander42 » Fri, Jul 01, 2016, 8:34 PM UTC

smss79 wrote: post #171

alehander42 wrote: post #169

Earlier quoted context omitted.

not the OP, but I've had a side project in Elixir and often I wanted to browse/play with some of the last saved models in repl. When I get the collection using `ecto`'s `Repo.all..` I can't just `bets[4]` or `bets[-2]`, I have to do weird gymnastics like `hd(tl(bets |> Enum.reverse))`

http://elixir-lang.org/docs/stable/elixir/Enum.html#at/3

thank you!

Re: Rails 5.0: Action Cable, API mode, and more

#213

Post by steveklabnik » Fri, Jul 01, 2016, 8:54 PM UTC

anonyfox wrote: post #185

steveklabnik wrote: post #180

Earlier quoted context omitted.

I really like Elixir and Erlang, but haven't found he time to play with Phoenix. But... > You're right basically, but the migration wave from > rails to phoenix has noticeably started, and > it shows. People have previously said this about: * Clojure * Node * Go And lots of things before that.

Sure! But this time (tm) it's different. Phoenix is a direct drop-in replacement for rails, with a bunch of strong benefits on top. Getting productive for a rails developer should be 1-2 weeks max, since one already knows how the framework works conceptually. The truly cool stuff happens when one learns how stuff works beneath the surface. While you're around: Elixir/Erlang in itself is a rather slow language when it…

  > But this time (tm) it's different.

Everyone always says that :) That said, your sibling comment makes good points here.

  > While you're around:

I think this idea is _really_ cool, but I'm not equipped to build such a thing, since I haven't had enough experience with them yet. I agree that that would be super cool.

Re: Rails 5.0: Action Cable, API mode, and more

#214

Post by out_of_protocol » Fri, Jul 01, 2016, 9:15 PM UTC

steveklabnik wrote: post #213

anonyfox wrote: post #185

Earlier quoted context omitted.

Sure! But this time (tm) it's different. Phoenix is a direct drop-in replacement for rails, with a bunch of strong benefits on top. Getting productive for a rails developer should be 1-2 weeks max, since one already knows how the framework works conceptually. The truly cool stuff happens when one learns how stuff works beneath the surface. While you're around: Elixir/Erlang in itself is a rather slow language when it…

> But this time (tm) it's different. Everyone always says that :) That said, your sibling comment makes good points here. > While you're around: I think this idea is _really_ cool, but I'm not equipped to build such a thing, since I haven't had enough experience with them yet. I agree that that would be super cool.

> Everyone always says that :)

Truth to be said: there were some good languages but never good frameworks. After rails it's really hard to touch these semi-baked flawed "rails copies". And Phoenix is the first framework that not only replicates good rails sides (other web frameworks failing even that) but also fixes most (actually important) rails issues.

Re: Rails 5.0: Action Cable, API mode, and more

#215

Post by nirvdrum » Sat, Jul 02, 2016, 12:42 AM UTC

ShaneOG wrote: post #189

nirvdrum wrote: post #63

Earlier quoted context omitted.

How granular are your measurements? I'm certainly not calling your experience into question. But I wanted to relay a cautionary tale of my own. On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried…

What did you replace redis-rb with, if you don't mind me asking?

In this case we first moved to JRuby (after verifying a similar performance profile to MRI) and once on JRuby we used jedis [1]. I simplified the tale a bit -- apologies if I got your hopes up on MRI.

[1] -- https://github.com/xetorthio/jedis

Re: Rails 5.0: Action Cable, API mode, and more

#216

Post by nirvdrum » Sat, Jul 02, 2016, 12:49 AM UTC

eric_h wrote: post #198

nirvdrum wrote: post #63

Earlier quoted context omitted.

How granular are your measurements? I'm certainly not calling your experience into question. But I wanted to relay a cautionary tale of my own. On one project my team was convinced that Redis was our bottleneck. Profiling was showing that Redis calls were where the most time was spent. I spent some time looking at the redis-rb source and it does a lot of block nesting (4 or 5 levels for every call, IIRC). So, I tried…

The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous service). Replacing it with em-hiredis (and refactoring to use callbacks) drastically improved throughput for us. In situations where a blocking redis client like redis-rb doesn't interfere with other running code (synchronous web requests), I've found zero perfo…

The tricky part with performance is it's often contextual. I didn't mention it, but I did verify the results by modifying redis-rb to remove the layers of blocks as well. Of course, it could have been something else, like how a particular method handled a block it was provided.

My intention wasn't to rail against redis-rb. It's written very nice, idiomatic Ruby. The faster solution was decidedly less Ruby-like. I was just suggesting that even when your profile looks to be telling you the DB is to blame, you should probably prod a bit more.

ActiveRecord is as another case where I've hit performance issues. I had just swapped out most AR usage for Sequel, so my data on that is probably well out-of-date. But, for us, materializing rows as full DAOs was often a very costly process that could dominate the cost of the DB query.

Re: Rails 5.0: Action Cable, API mode, and more

#217

Post by sams99 » Sat, Jul 02, 2016, 1:27 AM UTC

smss79 wrote: post #170

sams99 wrote: post #151

Earlier quoted context omitted.

jeez where are those numbers coming from :) For Discourse which we host in general we spend HALF the time in database calls and say 20-30% of the time in ActiveRecord bullshit. Lets say we erased all of the app cost using some magic, we would still only be saving 50%, so twice as fast, now erase some ORM bullshit, say another 50% faster, so at a super ambitious totally unrealistic setting we could be 4x faster. For a…

I would say languages that can leverage concurrency and do pooling well will generally put less pressure on the database for the same load. Rails in particular is very wasteful in terms of connection management, typically checking out the database connection for the duration of the whole request. If you have a machine with 4 cores, one of Rails deployments would start 4 processes each with 10 database connections. So…

Sure, but what is stopping you from choosing a more efficient architecture for your Rails app?

For example, we use pgbouncer transaction pooling, so our connection counts are low. Tons of caching is done in NGINX and first middleware in the stack, we are not afraid of using SQL where needed for performance reasons and so on.

For an application that is taking data from a database and turning into JSON or HTML, spending 50% of the time in the database is not really a crime of bad architecture. In fact even when we built Stack Overflow in superfast C# we often saw a similar breakdown.

I just really object to the sentiment of "abandon ship" Y is 12x faster.

Re: Rails 5.0: Action Cable, API mode, and more

#218

Post by mooreds » Sat, Jul 02, 2016, 2:27 AM UTC

sergiotapia wrote: post #207

mooreds wrote: post #173

Earlier quoted context omitted.

Depends on who is building it, who is supporting it after it is built, etc. I have seen companies with "technology sprawl" where project after project was done in the shiny new thing. No thanks, it's an ops and maintenance nightmare. Not to say you shouldn't choose this solution, just do it with an eye to the future.

Elixir is firmly planted in that future.

Good on ya.

Re: Rails 5.0: Action Cable, API mode, and more

#219

Post by eric_h » Sun, Jul 03, 2016, 10:06 PM UTC

nirvdrum wrote: post #216

eric_h wrote: post #198

Earlier quoted context omitted.

The performance problems I've had with redis-rb were largely due to my accidentally using it in an improper environment (an event machine based asynchronous service). Replacing it with em-hiredis (and refactoring to use callbacks) drastically improved throughput for us. In situations where a blocking redis client like redis-rb doesn't interfere with other running code (synchronous web requests), I've found zero perfo…

The tricky part with performance is it's often contextual. I didn't mention it, but I did verify the results by modifying redis-rb to remove the layers of blocks as well. Of course, it could have been something else, like how a particular method handled a block it was provided. My intention wasn't to rail against redis-rb. It's written very nice, idiomatic Ruby. The faster solution was decidedly less Ruby-like. I was…

Yes indeed, context is everything. I've had my own troubles with activerecord as well.

Re: Rails 5.0: Action Cable, API mode, and more

#220

Post by ansonhoyt » Tue, Jul 05, 2016, 11:53 AM UTC

jbackus wrote: post #33

I feel bad for Sean Griffin. He spent over a year overhauling the internals of ActiveRecord to add this attributes API. His work dramatically improves coercion and type enforcement for ActiveRecord users. Seems weird for this to only get a non-descriptive bullet point in "other highlights." Here are the docs if anyone is interested: http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribut...

Agreed, the attributes API work is perhaps the top improvement for me.