Live data from Hacker News

Moving my serverless project to Ruby on Rails

frantic.im

181–189 of 189 posts

Re: Moving my serverless project to Ruby on Rails

#181

Earlier quoted context omitted.

I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video. But 2k requests per second with mostly text content being shuffled around sounds absolutely doable with Rails. The cost benefit of easier development should definitely not be understated as well. But that being said, the primary driver for tools should be what the developers know and ease of access findi…

> I don’t want to second guess technical decisions I know nothing about but: no, Rails shouldn’t be streaming video. Yeah, if you are serving video at that rate, there are plenty of CDNs to work with, why would you submit your app engine to that.

If a Rails back-end streamed video, there wouldn't literally be a loop written in Ruby shoving bytes back and forth stored in Ruby arrays or buffers. It would be farmed off to something appropriate. You wouldn't necessarily want that machine to be doing it, using any middleware.

Re: Moving my serverless project to Ruby on Rails

#182
post #150

Earlier quoted context omitted.

I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…

Rails makes it really easy to do something 10 different ways to get the same result. Unfortunately, most of which aren't the most performant way. In my 10 years of building Rails apps of all different sizes, and seeing some very mature apps in production, this is the most common culprit I've seen. I currently work on a rather large Rails app for a site that most of us here use. A common pattern for our performance pi…

The general problem you describe - n + 1 queries caused by needless iterating over / instantiating Ruby objects when a simple SQL query would do - is certainly a very common newbie mistake, but it's just that: a newbie mistake.

Confusion here simply shouldn't be a problem for even a moderately seasoned developer, and if they do make such a mistake (because hey, we all make mistakes...) in performance-sensitive code they could quickly recognize it for what it is - a bug - and fix it.

If you're hiring junior developers, on the other hand? Sure! But you should know what you're getting, and your code review / mentoring process should get them straight.

I'm not sure I really understand how this is Ruby's or Rails' fault, unless your premise is "ORMs considered harmful" - in which case, ActiveRecord is far from alone here, and that's a different sort of conversation.

Re: Moving my serverless project to Ruby on Rails

#183
post #76

Also consider giving Crystal lang a look, in particular the Amber and Lucky web frameworks. Amber in particular is designed to feel just like Rails and accomplishes that pretty well in my opinion. Crystal is designed to feel like Ruby but to be "fast like C". I think in reality by adding a type system it manages to be better than Ruby. Small but very welcoming community with a number of startups and companies running…

I jumped on Crystal early and had significant pain, even just building hello worlds. After too much wasted effort I decided to punt and return at 1.0 Has Crystal stabilized?

I've used crystal (mostly kemal) for almost 1 year and the updates have not been too often and have not broken much.

Re: Moving my serverless project to Ruby on Rails

#185
post #76

Also consider giving Crystal lang a look, in particular the Amber and Lucky web frameworks. Amber in particular is designed to feel just like Rails and accomplishes that pretty well in my opinion. Crystal is designed to feel like Ruby but to be "fast like C". I think in reality by adding a type system it manages to be better than Ruby. Small but very welcoming community with a number of startups and companies running…

I jumped on Crystal early and had significant pain, even just building hello worlds. After too much wasted effort I decided to punt and return at 1.0 Has Crystal stabilized?

Crystal itself has stabilized quite nicely. Amber/lucky are a bit slow to update, but all of my production apps use either Kemal or Spider Gazelle which are too lightweight to matter in that regard.

Re: Moving my serverless project to Ruby on Rails

#186
post #3

I've seen a lot more discussion of Ruby recently than in past years, and maybe I'm just finding what I'm on the lookout for, but either way it makes me happy :)

It is a combination of factors.

It is not that Ruby suddenly popular again, the scaling issues is still there, Scaling not impossible but mostly have to do with being expensive. If you are an average dev in UK or US with 100K+ Salary of course scaling is cheap. But not everyone has that luxury or operate on the same budget. But the combination of Ruby and Rails getting faster and Hardware is finally getting cheaper. ( 128 Core EPYC, on a 2 Socket Server Changes the Unit Cost of Core per VM across the whole industry ) Along with wages rises across other part of the world.

And the world has finally woken up to may be Javascript Ecosystem isn't exactly what they have hoped for in the backend.

Re: Moving my serverless project to Ruby on Rails

#187
post #171

Earlier quoted context omitted.

Could you go into more detail about what you see as issues with IO bound tasks? My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL. Is there some other issue related to that? (JRuby provides fully multi-threading for cpu bound tasks without GVL).

"My understanding is that MRI Ruby provides non-block IO operations if you wrap them in a thread and that it is only CPU bound tasks that are blocked by the GVL." All IO operations in ruby are subject to the GIL (global interpreter lock).

GVL is an implementation detail rather than a feature of the language (I believe the term Global VM Lock replaced GIL in the standard library, sometime around ruby 2.0ish I think).

JRuby, for example, has no GVL including for CPU based code; everything there can run in parallel.

Even in MRI Ruby though, wrapping IO operations in a thread allows you to release the GVL when the IO operation blocks.

e.g.

  5.times.map do
    Thread.new do
      Net::HTTP.get('example.com', '/index.html')
    end
  end.each(&:join)
Will perform those network requests in parallel rather than sequencially. This is how ActiveRecord can perform asynchronous database calls in parallel on MRI Ruby.

I got that HTTP example from[1], which has a good write up but it's also covered in Working with Ruby Threads by Jesse Storimer[2].

I asked the original question because in the Concurrent-Ruby Readme they discuss Ruby's mutable references and the possibility of thread safety issues because of that.[3]

1. https://pawelurbanek.com/ruby-concurrent-requests

2. https://www.goodreads.com/book/show/17826435-working-with-ru...

3. https://github.com/ruby-concurrency/concurrent-ruby

Re: Moving my serverless project to Ruby on Rails

#188
post #150

Earlier quoted context omitted.

I’m also a big fan of rails, but I’ve experienced a lot of problems scaling it. A lot of the problems ultimately came down to the simple fact that Ruby is really, really slow. At a certain scale you end up forced to develop infrastructure on a different stack to keep up with the CPU load. I never ran into that so quickly when building similar systems with java, go, and C#. I wanna say something nice about rails too s…

Rails makes it really easy to do something 10 different ways to get the same result. Unfortunately, most of which aren't the most performant way. In my 10 years of building Rails apps of all different sizes, and seeing some very mature apps in production, this is the most common culprit I've seen. I currently work on a rather large Rails app for a site that most of us here use. A common pattern for our performance pi…

I would refactor your second example into an exists using Arel, because at best the IN will result in the same performance. At worst it will be significant my slower. There are also particular issues with NOT IN and NULL. This is at least true in PG.

I also deal with a lot of scale, the issues people have here doesn’t match my reality. I think people have issues and rather than looking at what is fundamentally happening with their call patterns, they jump to calling out rails itself.

Rails does have some specific issues, but you’d have to go pretty deep to see them and boot times are terrible.

Re: Moving my serverless project to Ruby on Rails

#189

Earlier quoted context omitted.

Which newspaper is hitting 2k req/s ?

For example: https://stackoverflow.com/a/373188 > Wikipedia seems to be 30000 to 70000 [requests] per second spread over 300 servers So 2k is not unusual for bigger news sites, that may or may not employ a (few) rails team(s).

That’s only 100-250rps per server, that’s really not very hard in any framework.

Financial exchanges are doing 100,000rps of transactions per sever. That’s hard.

Post reply on HN