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.
Moving my serverless project to Ruby on Rails
181–189 of 189 posts
Re: Moving my serverless project to Ruby on Rails
#182Earlier 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…
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
#183Also 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?
Re: Moving my serverless project to Ruby on Rails
#184Re: Moving my serverless project to Ruby on Rails
#185Also 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?
Re: Moving my serverless project to Ruby on Rails
#186I'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 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
#187Earlier 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).
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...
Re: Moving my serverless project to Ruby on Rails
#188Earlier 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 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
#189Earlier 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).
Financial exchanges are doing 100,000rps of transactions per sever. That’s hard.