11–20 of 24 posts
Earlier quoted context omitted.
I'd love to see a 'phusion passenger for background tasks'. Managing large amounts of resque workers is a pain.
That is a great suggestion, and it has actually been on our minds of a while now.
If the phusion passenger people built a plugin for cpanel that gave easy installation and configuration of ruby/pythons app, I really think it could disrupt the php monopoly on cheap hosting for mid level web devs. Deployment would be vastly eased to the same php strategy of "just ftp the files to the server and visit the website".
I don't think RoR and "cheap hosting" are compatible. RoR adds a maintenance overhead that kills the "cheap" part.
I did admin work for RoR "cheap hosting" and it sucks; lots of gems and multiple versions of them to install etc; this took a lot of my time and made security audits very hard, plus it's not always trivial to install them as some require NEW everything.
Whereas with PHP, 99,9% of the applications run just fine with a relatively simple PHP installation: e.g. core + xml, mysql, imap, gd, mbstring, mcrypt. Update it every once in a while and you're all set!
What RoR programmers need is a cheap vps/container with RVM (or similar) or very specialised platforms (e.g. Heroku).
If the phusion passenger people built a plugin for cpanel that gave easy installation and configuration of ruby/pythons app, I really think it could disrupt the php monopoly on cheap hosting for mid level web devs. Deployment would be vastly eased to the same php strategy of "just ftp the files to the server and visit the website".
As an admin who unfortunately has to deal with "cheap hosting" quite often I'd say "Please, NO!" to that. I don't think RoR and "cheap hosting" are compatible. RoR adds a maintenance overhead that kills the "cheap" part. I did admin work for RoR "cheap hosting" and it sucks; lots of gems and multiple versions of them to install etc; this took a lot of my time and made security audits very hard, plus it's not always t…
I can't imagine wheat it'd be like on a shared host with 100 apps all made by different people.
Check out this new Phusion Passenger 4.x series. It has much, MUCH improved performance, stability and features that rivals that of Unicorn, Puma, etc. It's used by the likes of New York Times, Symantec, AirBnB, etc. The main reason why people use Phusion Passenger is because of its ease of use. The way it integrates into Apache and Nginx is unlike other app servers and saves a lot of administration time and effort.
Update process loads our application once and forks it to all the workers like Unicorn does. Puma wanted to load the application as many times as we had workers, which caused a huge spike every time we deployed.
Same goes to the thread handling. It really seems Passenger is the only Ruby server able to handle massive loads with threaded Rails app. Money well spent.
Check out this new Phusion Passenger 4.x series. It has much, MUCH improved performance, stability and features that rivals that of Unicorn, Puma, etc. It's used by the likes of New York Times, Symantec, AirBnB, etc. The main reason why people use Phusion Passenger is because of its ease of use. The way it integrates into Apache and Nginx is unlike other app servers and saves a lot of administration time and effort.
Our reason to use the Passenger Enterprise version is that it's the only truly reliable application server for Ruby that handles threads good enough. The administration tools and how it handles stuff like deployment upgrades to a huge application server are done remarkably better than in any other Ruby app server. Update process loads our application once and forks it to all the workers like Unicorn does. Puma wanted…
How can we improve Phusion Passenger? We're very open to feedback from HN readers. If you have any suggestions, please let us know. If you have any questions about it please feel free to ask.
I'd love to see a 'phusion passenger for background tasks'. Managing large amounts of resque workers is a pain.
Earlier quoted context omitted.
As an admin who unfortunately has to deal with "cheap hosting" quite often I'd say "Please, NO!" to that. I don't think RoR and "cheap hosting" are compatible. RoR adds a maintenance overhead that kills the "cheap" part. I did admin work for RoR "cheap hosting" and it sucks; lots of gems and multiple versions of them to install etc; this took a lot of my time and made security audits very hard, plus it's not always t…
We have 15-20 apps that all run different versions of gems (including Rails 1-3) and it can be a nightmare. Nobody ever decided to use RVM or anything like that. A while ago you could update a gem and break 3 apps. I can't imagine wheat it'd be like on a shared host with 100 apps all made by different people.
You aren't using bundler, are you? You really really should be. It eliminates the vast majority of that class of problem. It's been best practice in Rails, and ruby deployment in general, to use bundler for several years now, it really does make that kind of problem go away.
Earlier quoted context omitted.
Our reason to use the Passenger Enterprise version is that it's the only truly reliable application server for Ruby that handles threads good enough. The administration tools and how it handles stuff like deployment upgrades to a huge application server are done remarkably better than in any other Ruby app server. Update process loads our application once and forks it to all the workers like Unicorn does. Puma wanted…
Thanks for the good words. :) Do you mind if we use this statement as a testimonial, with your real name and company name?
Earlier quoted context omitted.
We have 15-20 apps that all run different versions of gems (including Rails 1-3) and it can be a nightmare. Nobody ever decided to use RVM or anything like that. A while ago you could update a gem and break 3 apps. I can't imagine wheat it'd be like on a shared host with 100 apps all made by different people.
> A while ago you could update a gem and break 3 apps. You aren't using bundler, are you? You really really should be. It eliminates the vast majority of that class of problem. It's been best practice in Rails, and ruby deployment in general, to use bundler for several years now, it really does make that kind of problem go away.