I need to host a lot of simple rails/sinatra/padrino applications of different ruby versions each with 0..low hits per day. They belong to different owners and should be well isolated from each other.
When an app is hit it should respond in reasonably short time, but I expect several simultaneous visitors are hitting the same site to be a rare case.
I'm going to create separate os user for each application. Surely I'd like to put them as many per server as it's possible. Thus I need to choose the web server with the lowest memory footprint, which can run applications on behalf of different users with different ruby versions and gemsets.
I consider webrick,nginx+passenger,thin,apache+passenger. I suppose the reliability of all choices is sufficient for such a job, and while performance isn't an issue, the memory consumption is.
I found many posts regarding performance issues, but most of them discuss the performance tuning and issues. I couldn't find a comparison of web servers memory usage when idle.
Is "in process" webrick the best choice? Which one would you choose for that job?
And I couldn't figure out how to resolve subdomains to application ports with webrick. Shall I use nginx or apache for that?
I don't have much experience with hosting myself, but using Webrick for production is not a good idea I think. You can also check out mongrel which I saw used in production. In most cases though you will probably want to choose between thin and unicorn. Check out this http://cmelbye.github.com/2009/10/04/thin-vs-unicorn.html or google around. Good luck :-)
Why not use Heroku? Its free and gets you out of the hassle of server configuration and maintenance.
Related
I am playing around with using Rails to underpin a kiosk. This is a terminal where there is only one local user at a time.
Under this system, a browser like Chrome would access the Rails app.
Things I assume would be helpful:
Super-fast, very lightweight Rails server (I'm using Puma).
Eliminating standard processes/assumptions that are meant for internet website contexts (caching, CDNs, middleware, etc.).
In some level of detail preferably, how should one set up a Rails app for maximum performance in a single-user kiosk?
This might sound like a non-answer, but the approach I would take is to use Rails in its default (production) configuration, and optimise performance issues as they arise in your test bed. Running Rails in production mode will likely give you more than enough performance if you have a dedicated machine for a single user (often you'll have many clients to a single Rails instance). Without testing the application, you could sink a considerable amount of time into optimisations that don't impact the user experience.
It may be worth sitting Rails behind Apache/nginx (Passenger is a well understood way to get a Rails app on Apache) to serve your static assets, but from the information provided so far I'd be surprised if performance optimisation was necessary at this stage.
A challenge that might be worth considering at this stage is how you'll deploy changes to your kiosk/set of kiosks. Will they be brought in for updates or need to have changes applied over-the-air? That will likely impact how you deploy it onto the machine, and in my experience is a harder thing to change later on.
I've been searching around for performance tests on the new passenger 5 as I read here it became way faster.
I tried to find other ressources confirming this but no luck. Has anyone tried to install it and see the difference?
Passenger 5 scores better on custom-picked benchmarks because it has a built-in caching layer ("turbocaching") that can avoid actually running your application code for identical requests in a short timeframe; it will not make your actual application code run any faster. This caching layer is only active in certain constrained situations, and is not likely to provide much benefit in the vast majority of actual cases. If you aren't careful, the caching layer may actually end up breaking your application - I demonstrated several security vulnerabilities due to the caching layer to Phusion during the 5 beta phase (which they fixed, at the cost of the caching layer not being able to cache nearly as much). IMO, the Raptor/Passenger 5 benchmarks are deceptive marketing fluff, and the caching layer exists primarily to win Hello World benchmarks, and you should probably just ignore them.
That said, the speed of your application server is almost certainly insignificant in the scope of your overall application performance. Passenger is a great platform because it's extremely user-friendly, well-documented, has an absolutely fantastic installer, and handles a lot of the annoying crap for you out of the box. You should use Passenger if you need the functionality it provides and don't want to screw around with a ton of config stuff. If it doesn't fit your use case, use something else that does.
If every last microsecond is of prime concern to you, you should measure your application's performance under various webservers and various workloads, and then pick the one that performs the best. Otherwise, use whatever you like the most and then switch once performance becomes an actual problem.
Footnote: If you do use Passenger 5, be sure to read the Turbocaching security changes article to be sure you don't accidentally make your application vulnerable to user data theft (or otherwise introduce bugs) through the turbocaching layer.
I recently migrated my app from Puma to Passenger.
I have to say that I'm really happy about this move, especially because I'm hosting it on Heroku.
Since I updated to Ruby 2.2, I had some memory issues with Puma due to Heroku memory limitation (512M).
I tried a couple of different configurations but without success.
Since I moved to Passenger, I saw the memory usage go down to almost half what I was consuming with Puma with the same number of server instances (3 in my case).
Regarding the response time, it seems to be pretty much the same as before but with those memory improvements. Although, I reduced my number of Heroku dynos to handle the same number of requests.
In conclusion, on my personal experience, Passenger helped me a lot reducing the memory used by the app but it didn't helped improving the average response time. Another good point is, regarding the Heroku pricing, it helped me a lot to reduce the cost of my hosting.
I know this post is not really exhaustive without any benchmarks etc... But I thought that maybe you could find it interesting to have a personal experience on a migration from Puma to Passenger.
Hope it helps :)
First of all, let's just be clear, when we talk about server performance, the question is about how well the server scales as usage increases. If your server has one or very few human users, for most apps, you will get the same end-user experience regardless of which server you use because the bottle-neck will be the performance of Ruby, not the app server.
For medium and large apps:
So let's talk about scaling. The more CPU power and RAM you have, the more you can scale. Most servers run out of RAM faster than CPU power. So the key is to minimize the amount of RAM used per request. Each request the server receives will be handled by a process or a thread. Processes use a lot of RAM, threads use very little RAM. So the goal is simply to have lots of threads and few processes.
Puma and Passenger Enterprise are both multi-threaded servers which will scale approximately the same. (Passenger's benchmarks claim to use 5MB less RAM per process, but this is negligible.) Passenger itself (the free version) is single threaded and will not scale as well as the paid Passenger Enterprise version or as well as Puma.
So if you want maximum performance, you're choosing between Puma and Passenger Enterprise. The question then becomes, is Passenger Enterprise worth the financial cost vs is Puma worth the technical expertise cost. The answer depends on what's in your brain(s), what's in your bank account(s), and your general opportunity cost.
Passenger Enterprise has some nice tools that hold your hand if you're not an expert system administrator. Puma also has some tools but they are not as powerful as what Passenger Enterprise provides. Puma requires system-level expertise if you want to get the same control and insights as Passenger Enterprise. (You can also use Puma without all the bells-and-whistles of Passenger Enterprise, but I want to keep this comparison "apples-to-apples").
Personally, I'm a low-level guy who loves configuring servers so I prefer to trade my time rather than my money for an awesome Ruby server. Therefore, I use Puma. If you're not interested in configuring low-level stuff (or if you're a company that realizes software licenses are cheaper than administrator-developers), you might be better off with a paid Passenger Enterprise license.
For the guy running a $5 VPS (or similar low-resource, low-traffic environment):
What I said above is more for higher-traffic apps on servers with considerable resources. You're just trying to get by with basics, so it does not really apply to you.
Think of Puma and Passenger Enterprise as jumbo jets that can move a lot of people very fast. That's way more than your little app needs. What you really need is the server equivalent to a Honda Civic. For that, you should consider either the free version of Passenger or Thin. Use free Passenger if you want easy setup and decent tools. Use thin if you want similar performance but have a willingness to engineer the server.
In this case, I see no reason to use anything but free Passenger unless you are looking for a challenge.
As others said, Passenger by itself doesn't make your app faster per se. Passenger itself has become a lot faster in version 5, but the app server is only a part of the response time. If your app is slow, then it doesn't matter how fast Passenger itself is.
Having said that, Passenger differentiates itself from other app servers by actively helping you to make your app faster. Passenger's turbocache is one way through which Passenger helps you. The article Dynamic Site as fast as a Static Generated One with Raptor demonstrates a good use case for the turbocache. Passenger also provides an optimization guide that gives you tips on how to optimize your app using Passenger settings.
I have a VPS which is hosting (currently) 5 different rails applications, all with different domains. To make them work I've added one server {} listener per app in my nginx config file. I've left everything else as default, for instance there's only one nginx worker process.
Concurrently, I also have 2 rails workers for one of the apps.
Now, this works as is, but performances are low, in particular speed. How could I make my apps quicker by adhering to my constraints?
Thanks!
Your problem is that you are deep into swap. The slowness you experiencing switching apps is the system loading the requested app from swap into physical memory.
To address this, you can observe who is hogging the memory (also using 'top'), and address that. It's possible you'll find some things to tune, but also quite possible you'll find that you are near the physical limits of what's possible without significant architectural changes.
If your time is worth much, your best course of action will be to upgrade to an instance with at least a 1GB of memory, because you are already using nearly that much.
The nginx "worker_processes" should be set to the number of cores that you have available to work with. You mentioned you had it set to 1. Do you have more cores than that?
Should i stay out of rails if a client has a cheap hosting service with a provider that do not support mod_rails? Will rails + fast.cgi provide a good experience for a user or should I choose, in this scenario, php + my-favorite-framework as platform ?
Regards,
Victor
Fastcgi should be fine. Though it has been generally recommended to host rails apps on a platform that you own. There are some pretty affordable virtual private servers out there that let you do this.
I have three clients on inexpensive hosting plans using FastCGI and have not run into any issues due to FastCGI itself. These are all low traffic sites where Mongrel was not necessary.
Will rails + fast.cgi provide a good experience for a user
It all depends on what you're trying to do. If you're going to build a site where users will uploading and playing video then no FastCGI is not a good choice.
or should I choose, in this scenario, php + my-favorite-framework as platform
You always choose the right tool for the job. Without any details on what you are trying to build I'm not sure anyone here will be able to tell you how to build it.
My experience on low end hosts was really really bad. Constantly having my mongrel instances die inexplicably. Since switching to a slice I have had zero problems running it on my own.
I would tend to avoid FastCGI. I haven't used it myself but I've read enough horror stories about it to never want to.
If the hosting company is going to be completely responsible for managing the server instance and you can trust them to be the ones who will make sure the app is always up and running, then maybe it would work. I doubt this is the case though, and if you don't own the servers I think you'll run into a lot of problems troubleshooting the all the weird bugs FastCGI will inevitably throw at you.
Don't worry about mod_rails: it's new and Rails sites were running fine before it turned up. It's nice to have, I'm sure, but not a necessity.
By the time you're looking to get rails to scale to volumes that really need mod_rails, the site should be worth putting into an environment that runs it.
I am actually developing and application that has around 15 modules, all of them using the same database.
I am using Apache + Mongrel, I cannot use Passenger because I am working on Windows (please forgive me for this deadly sin!)
Which of the following is a better approach?
Deploy multiple small rails
applications using a virtual server
and a pair of mongrels for each
application.
Deploy only a big rails application
I am worried about the number of running mongrels and the memory/cpu load.
I'd suggest deploying a monolithic Rails application.
I use the request_routing plugin to drive 3 domains sharing the same database from one, big Rails application.
I'm running 4 mongrels, which seems to be enough for now, but YMMV.
It depends on hwo many simultaneous clients you expect to have. One mongrel, one client at a time (until Rails 2.2) since Rails isn't currently threaded.
Two is enough mongrels if you don't expect more than a few simultaneous users. You can raise that number by using page caching to bypass mongrel for pages that don't have user-specific dynamic content.
The only way to be truly sure is to test the system.
In my experience you'll need at least 4 mongrels for a moderately active site of just a few users at a time.
It would seem like one application would best fit your scenario... as others have said...
A good rule of thumb would be that the average behaving mongrel will consume 60mb of memory (or less)... take your total RAM available, subtract out for any other services (database, memcache, etc) and then figure out how many pieces of the pie you can have left from the remaining memory.
You can always scale them up or down from there...
It sounds like it would be a much better use of your hardware to integrate all modules into one comprehensive rails apps.
IMHO the primary weakness of Rails is the amount of resources needed to run a low or very low traffic app. On the other hand a few mongrels go a long way to serve a whole lot of traffic.