> It's also about proper threading support, something that so many > "scripting" languages still sorely lack, unfortunately, > with giant lock-based interpreter designs etc.
Yup, so they fall back on thread-per-process models, which works, but is quite a pain.
I hear a lot about Ruby performance - specifically, "Ruby/Rails can't scale". The odd thing is that this is in the context of a web app, where the overhead of the interpreter opcode execution is dwarfed by the cost of going over a socket to pull data across a LAN from a database. Scaling a web app isn't about the language; it's about architecture, judicious SQL optimizations, and caching.
Oh, and if you're using rcov to measure your Rails app's code coverage, try this patch to prevent rcov segfaults. It doesn't fix the root problem, but it's a start.
Just run it with "-xX" and see what it finds in terms of XSS vulnerabilities... I used it this afternoon on an app and found a bunch of stuff. Some problems were tricky, other problems were simple ones of the "alert('hi')" variety. And it's in C so it's fast enough to browse through without being annoying. RatProxy + FireBug make a great combo. Thanks Google!
> In cases like these, it seems like you'd more > often be looking to background the task.
I guess I'm thinking of thing like a 2-3 second call to a service. With mongrel, that's one member of the cluster that's used up for the duration of that call. With modrails, Apache will just start up another worker as needed.
> gem install mongrel_cluster
I guess here I was thinking of something like monit or god to watch the individual cluster member and restart them as needed. I didn't think the mongrel_cluster gem did any of that...
> Out of curiosity, what would scaling the cluster size down accomplish? > We're pretty much putting apps on dedicated app servers on EC2.
You're right, in that situation a dynamically resizable cluster may not buy you anything.
> If I wanted something like a PHP app, I'd grab Sinatra, or maybe Camping.
Camping's fun stuff; another fine piece of work from _why...
> Given two cores, I'm not sure where > more than three mongrels would help
Hm, but isn't that assuming that they're CPU bound? I'd think they'd be more likely to be I/O or socket bound, especially if they're dealing with file uploads or calls to S3 or Salesforce or any other long-lasting requests.
> Actually, you do -- it's called Apache+modrails. The only > difference is that it's marginally more visible when used as mongrel_cluster.
Right, and modrails handles that, so I don't need to see anything else up as a watchdog.
> My cluster right now is: nginx -> mongrels (with rails) -> db
Ah, ok, so nginx is the load balancer.
> With modrails, it'd be: nginx -> apache (with modrails) -> db
Yup, right on. The nice thing is that I wouldn't need to have nginx know how many mongrel instances were on each host; instead, I just point it to port 80 on each app server and let modrails handle the cluster size based on the current load.
> if you're running on a single machine
Quite right, yup, then it's just like a PHP app - set up Apache, set up the DB, and away you go.
> You still need to setup a reverse proxy to the other servers. > The only thing you've done is replaced mongrel with apache.
Yes, but instead of preallocating a specific port range (and a cluster size) you can set up one port and the number of workers gets expanded as necessary. Plus, you don't need something watching and restarting each worker. Also, you could conceivably remove a layer from your server architecture - rather than:
load balancer web app db
we can have:
load balancer app db
And you're not setting up a mod_proxy_balancer pool, just a simple proxy entry. Rather nice!
...is a fine book by M. Tim Jones if you want a nice overview of programming some "AI" techniques. I wrote up a review of it on Freshmeat. There's a second edition out now... and here's a translation of some of the example code from C to Ruby.
> it's trivial to put a few more mongrels on another machine.
True, and right, once you get all the parts (init scripts, monit, ports, etc) working, it's done. But all that goes away with modrails... just keep Apache running and you're all set. Just a lot fewer moving parts. The horizontal scaling is still there, modrails just removes a layer from the architecture - which is nice...
No problem! Yup, the thing I like about modrails is that I don't have to allocate my cluster sizes and port ranges and such up front - I can just set RailsMaxPoolSize and then let modrails spin application instances up and down as needed. I used to worry about file uploads - you know, "oh gosh, what if 4 people are uploading files at once, they'll tie up the whole cluster, so let's restrict uploads to just mongrels on ports 8000-8001" - that kind of thing. Nice not to have to worry about that stuff anymore.
> 70% of most code is just common-everyday stuff that doesn't > NEED to be documented in the sense that comments are completely wasteful.
So true! Rather than this code: # Finds the most recent orders for the passed in person def get_rec(p)
# blah blah end
I'd much rather see an intention-revealing method name (hat tip Marcel Molina): def find_recent_orders_for(person)
# blah blah end
I'm still not really sure what documentation is really useful - maybe a few diagrams plus some use case descriptions that go through the code, maybe? I'm not sure. I guess it depends on the project - it is a widely used library? Is it an internal department app to track the coffee fund? etc.
My experience with open source code has been that the large projects have decent docs... I was just reading through some of the PostgreSQL docs on backups this weekend and they're quite good.
> So this is one to which I say, "I'll believe it when I see it, not before."
Yup, that's fair enough. But I hope that I've opened port ranges and set up init scripts and monit.conf files and mongrel_cluster.yml and proxy_balancer settings for the last time. No more need to worry about a dozen people doing slow file uploads and locking all the Mongrel processes... all those pieces of the puzzle just go away. Good times.
> why do your "little toy apps" need init scripts in the first place?
Because I want them to start if the machine gets restarted.
Re:I converted our corporate site from PHP to RoR
on
Practical Rails Projects
·
· Score: 2, Interesting
> and all I got was a pinkslip
You should have used modrails. Suddenly, Rails deployment is as easy as PHP deployment. I no longer hesitate to put up little toy apps since now I don't have to worry about mongrel clusters and init scripts and all that rot. Great stuff!
> it frequently fails to explain the fundamental > Ruby concepts and structures that it's using.
David Black's Ruby For Rails is a great book for this; David explains the way Rails leverages all sorts of Ruby techniques to do what it does. Another good one is Advanced Rails, which has an excellent section on the changes that Rails makes to various Ruby core classes - e.g., Symbol.to_proc.
When I worked on the DARPA COUGAAR distributed agent project they used lots of open source code and had no problems with donating code back. The whole PMD source code analysis tool started there and has lived on long after the sponsoring program ended... good stuff.
Yup, and the author of the paper is Diomidis Spinellis, who wrote the excellent book Code Reading. This is a great study of code analysis and familiarization techniques. He also wrote a fine article on C preprocessors... in Dr. Dobb's Journal, I think.
Slashdot Mirror
> It's also about proper threading support, something that so many
> "scripting" languages still sorely lack, unfortunately,
> with giant lock-based interpreter designs etc.
Yup, so they fall back on thread-per-process models, which works, but is quite a pain.
I hear a lot about Ruby performance - specifically, "Ruby/Rails can't scale". The odd thing is that this is in the context of a web app, where the overhead of the interpreter opcode execution is dwarfed by the cost of going over a socket to pull data across a LAN from a database. Scaling a web app isn't about the language; it's about architecture, judicious SQL optimizations, and caching.
Oh, and if you're using rcov to measure your Rails app's code coverage, try this patch to prevent rcov segfaults. It doesn't fix the root problem, but it's a start.
Just run it with "-xX" and see what it finds in terms of XSS vulnerabilities... I used it this afternoon on an app and found a bunch of stuff. Some problems were tricky, other problems were simple ones of the "alert('hi')" variety. And it's in C so it's fast enough to browse through without being annoying. RatProxy + FireBug make a great combo. Thanks Google!
NICE!
> If you like Camping, you'll love Sinatra. Not MVC, but still awesome.
Cool, I had seen a couple of RubyForge news items float by but never looked at it, maybe I will now, thanks!
> In cases like these, it seems like you'd more
> often be looking to background the task.
I guess I'm thinking of thing like a 2-3 second call to a service. With mongrel, that's one member of the cluster that's used up for the duration of that call. With modrails, Apache will just start up another worker as needed.
> gem install mongrel_cluster
I guess here I was thinking of something like monit or god to watch the individual cluster member and restart them as needed. I didn't think the mongrel_cluster gem did any of that...
> Out of curiosity, what would scaling the cluster size down accomplish?
> We're pretty much putting apps on dedicated app servers on EC2.
You're right, in that situation a dynamically resizable cluster may not buy you anything.
> If I wanted something like a PHP app, I'd grab Sinatra, or maybe Camping.
Camping's fun stuff; another fine piece of work from _why...
> Given two cores, I'm not sure where
> more than three mongrels would help
Hm, but isn't that assuming that they're CPU bound? I'd think they'd be more likely to be I/O or socket bound, especially if they're dealing with file uploads or calls to S3 or Salesforce or any other long-lasting requests.
> Actually, you do -- it's called Apache+modrails. The only
> difference is that it's marginally more visible when used as mongrel_cluster.
Right, and modrails handles that, so I don't need to see anything else up as a watchdog.
> My cluster right now is: nginx -> mongrels (with rails) -> db
Ah, ok, so nginx is the load balancer.
> With modrails, it'd be: nginx -> apache (with modrails) -> db
Yup, right on. The nice thing is that I wouldn't need to have nginx know how many mongrel instances were on each host; instead, I just point it to port 80 on each app server and let modrails handle the cluster size based on the current load.
> if you're running on a single machine
Quite right, yup, then it's just like a PHP app - set up Apache, set up the DB, and away you go.
> You still need to setup a reverse proxy to the other servers.
> The only thing you've done is replaced mongrel with apache.
Yes, but instead of preallocating a specific port range (and a cluster size) you can set up one port and the number of workers gets expanded as necessary. Plus, you don't need something watching and restarting each worker. Also, you could conceivably remove a layer from your server architecture - rather than:
load balancer web app db
we can have:
load balancer app db
And you're not setting up a mod_proxy_balancer pool, just a simple proxy entry. Rather nice!
...is a fine book by M. Tim Jones if you want a nice overview of programming some "AI" techniques. I wrote up a review of it on Freshmeat. There's a second edition out now... and here's a translation of some of the example code from C to Ruby.
> it's trivial to put a few more mongrels on another machine.
True, and right, once you get all the parts (init scripts, monit, ports, etc) working, it's done. But all that goes away with modrails... just keep Apache running and you're all set. Just a lot fewer moving parts. The horizontal scaling is still there, modrails just removes a layer from the architecture - which is nice...
No problem! Yup, the thing I like about modrails is that I don't have to allocate my cluster sizes and port ranges and such up front - I can just set RailsMaxPoolSize and then let modrails spin application instances up and down as needed. I used to worry about file uploads - you know, "oh gosh, what if 4 people are uploading files at once, they'll tie up the whole cluster, so let's restrict uploads to just mongrels on ports 8000-8001" - that kind of thing. Nice not to have to worry about that stuff anymore.
+1 on memcached, yeah, great stuff there!
> I have dealt with deployment and scaling issues for a few years
What do you think of modrails? To me it changes the Rails deployment game entirely... no more mongrel clusters, no more complicated rewrite rules...
> it only does what I need it to do right now. :-)
Cool, sure, no harm done there!
> This is where my lexer+parser comes into play -
> I can generate complete call graphs over our system
That's very cool! Do you do data flow analysis as well?
> 70% of most code is just common-everyday stuff that doesn't
> NEED to be documented in the sense that comments are completely wasteful.
So true! Rather than this code:
# Finds the most recent orders for the passed in person
def get_rec(p)
# blah blah
end
I'd much rather see an intention-revealing method name (hat tip Marcel Molina):
def find_recent_orders_for(person)
# blah blah
end
I'm still not really sure what documentation is really useful - maybe a few diagrams plus some use case descriptions that go through the code, maybe? I'm not sure. I guess it depends on the project - it is a widely used library? Is it an internal department app to track the coffee fund? etc.
My experience with open source code has been that the large projects have decent docs... I was just reading through some of the PostgreSQL docs on backups this weekend and they're quite good.
...seem to be based on green power and big unions. Nothing to do with capitalism...
> So this is one to which I say, "I'll believe it when I see it, not before."
Yup, that's fair enough. But I hope that I've opened port ranges and set up init scripts and monit.conf files and mongrel_cluster.yml and proxy_balancer settings for the last time. No more need to worry about a dozen people doing slow file uploads and locking all the Mongrel processes... all those pieces of the puzzle just go away. Good times.
> why do your "little toy apps" need init scripts in the first place?
Because I want them to start if the machine gets restarted.
> and all I got was a pinkslip
You should have used modrails. Suddenly, Rails deployment is as easy as PHP deployment. I no longer hesitate to put up little toy apps since now I don't have to worry about mongrel clusters and init scripts and all that rot. Great stuff!
> I am no longer a Ruby on Rails fan as I have found
> more and more people complain about scalability.
Remember, languages (and frameworks) don't scale, architectures do.
> There have been numerous companies that have abandoned ship.
From where I stand there are lots of companies getting onboard, and modrails is a sea change (for the better!) in the Rails deployment story.
> it frequently fails to explain the fundamental
> Ruby concepts and structures that it's using.
David Black's Ruby For Rails is a great book for this; David explains the way Rails leverages all sorts of Ruby techniques to do what it does. Another good one is Advanced Rails, which has an excellent section on the changes that Rails makes to various Ruby core classes - e.g., Symbol.to_proc.
> Hate to say it but the Cougaar link is dead one.
:-)
Oops, yup, must have killed it... ah well, at least the PMD link lives on
> The preprocessor algorithm I described in the Dr. Dobb's article
> is the one I used for parsing the code of this study.
That was a great article; it really showed the complexity of handling those macros. Maybe something for "Beautiful Code II"...
When I worked on the DARPA COUGAAR distributed agent project they used lots of open source code and had no problems with donating code back. The whole PMD source code analysis tool started there and has lived on long after the sponsoring program ended... good stuff.
> the paper is well-written
Yup, and the author of the paper is Diomidis Spinellis, who wrote the excellent book Code Reading. This is a great study of code analysis and familiarization techniques. He also wrote a fine article on C preprocessors... in Dr. Dobb's Journal, I think.