I'm running my Rails application through thin on Windows OS.
thin start -e production
Since the number of users grew, now around 10 people using the app simultaneously, there are times when a same page takes a while longer to load.
Are there other configurations that I need to set when running the server on production?
I'm quite sure that it has to do with the server since the slow down happens on pages that normally loads fast.
The Thin webserver is not meant to production environment. Instead of this you should use a different webserver and application server like Nginx/Unicorn, Nginx/Passenger.
I would recommend Passenger to run your rails app as fast as possible in production mode.
The thin webserver is very fast for few requests, but if there are simultaneously requests, thin gets very slow.
The following document describes about how to deploy rails application in windows. I haven't done this personally but, believe the latest versions should allow that. Please check the below link to see how it can be done
http://weblog.rubyonrails.org/2006/5/11/deploying-rails-on-windows-servers/
Related
I was wondering if there was a way to use the Puma server (Rails default) JUST on the new Rails 5.1 system tests?
Right now on all our projects we use tiny_tds, but I was trying to experiment with 5.1 system tests with Capybara/Selenium but it fails of course because I do not have Puma installed/running.
I took a look through the documentation and didn't see anything about declaring what type of server you want to use. Were connecting to a SQL Server database so I don't know if Puma is able to do that (And that's probably why were using tiny_tds in the first place).
You're confusing database adapters and rack web servers which are very different things.
Puma (like Webrick, Thin, Unicorn etc) is a general purpose Rack web server. It sits and waits for incoming requests from vistors and dispatches them to an application (like a Rails app) by calling it with a hash containing the environment and request. The application returns an array containing the response. The server sends it back to the visitor.
tiny_tds on the other hand is a database adapter. Its used to connect the application to the database. The web server is almost completly oblivious to how the application creates a response from the request. This includes whatever databases are used.
In Rails 5 most servers don't require configuration. You just add the gem to the gemfile and run bundle install and they plug themselves in. There in no seperate installation step.
That was not the case earlier which is why Webrick - a server with the only real merit being that it does not require configuration was the default. It is now Puma which unlike Webrick is suited for production.
Using different servers in different environments is not a good idea since it violates the idea of dev/prod parity. Your dev & test environment should be as close as possible to what you are deploying to so that you can catch bugs before they end up in production. This means you should be running the same server, same database etc.
Running a seperate test server for different parts of your test suite sounds like a true fools errand - if its even possible without hacking the framework to bits.
For SQL Server there is activerecord-sqlserver-adapter which can use tiny_tds as a backend.
I have two questions about rails server:
Do I have to start the server from within the application folder?
Is the server I started only for that application?
If they are true, this does not quite make sense to me, since why do I need to start multiple servers?
Or is there some kind of master configuration, so that one server can route to different applications? Is Capistrano for this purpose?
I'm going to assume you're talking about the rails server command, for running a local rails server to test your application, and that you're not talking about setting up a rails application on a remote server. Please mention if that is not the case.
Yes, you must execute rails server from within the root folder of your rails application.
Yes, the server you started is only for that application. It's a self-contained thing.
You should not need to start multiple servers. Even if you have multiple applications, you probably don't need to have more than one running at a time. So, you can shut down the rails server in one application (Ctrl-C) and then cd to your new application, and start a new rails server there with rails server.
If you do need to run two local rails applications at once, you can do so by running them on different ports. So, the first one, you can just execute rails server and it will make your site available at localhost:3000 (because port 3000 is the default port). The next one, you can specify a port other than 3000 - eg. rails server -p 3001 to get a rails app at localhost:3001.
Capistrano is for deploying your applications to a remote server, not for running them locally on your own computer. So, it is not relevant here. What you may be interested in is http://pow.cx/
Again, I've assumed you're talking about running your rails app locally on your own computer. If you're referring to deploying it to the internet on a server, then you can ignore this answer.
Is it possible to hot deploy Ruby just like PHP?
Normally I used FTP to upload the PHP file, then it will be available automatically.
Can Ruby hot deploy its file like this?
Your comment welcome.
Are you talking about a ruby on rails application ?
If so, when deploying a rails application in production mode, the all application gets loaded in memory. So changing the files won't affect the running application.
For hot restarting a rails application you will need to use solution such as:
Unicorn
Puma
Passenger
For a first time, Puma is the easiest way.
However if you are looking for a zero-downtime, either Unicorn or Passenger enterprise are what you are looking for.
EDIT
Unicorn
Free
Complex configuration
zero-downtime when hot restarting. when hot-restarting unicorn, it keeps the old threads working until the new ones are fully functionnal. So if the new ones fail to start, nothing happens. The old ones just keep going.
Puma
Free
Simple configuration
hot restart but no zero-downtime. When hot-restarting puma, it shuts down the old threads and starts the new ones. Puma keeps the sockets open, so the client are not disconnected, but are waiting to get a response while the new threads restart. However if the new threads fail to start, Puma can't restart the old ones. So connections are lost and the server is down.
Passenger
Free edition
Free
The configuration is easier than unicorn
hot-restart, but no zero-downtime. Like Puma.
Enterprise edition
$29/mo
The configuration is easier than unicorn
zero-downtime when hot restarting. Like Unicorn.
I'm trying to automate the deployment of multiple rails applications in one server with nginx + passenger. I have one server block for each application...
My problem is that everytime that I insert a new rails application to nginx I need to reload the config file and every rails application is reloaded. The reload with passenger takes a while because passenger loads all rails app to memory in first access...
I want to avoid this load time but i really don't know how.
Is possible to load only 1 server with nginx? Or should I have 1 nginx instance for each rails app (don't know if this is possible)?
Should I use other ruby app server? Probably thin would be faster on 1st load...
Thanks for your time.
Unicorn sounds like it might be a better fit for your deployment scenario. You can keep nginx up front, but instead of loading rails itself, it will just connect to a unicorn Unix socket. Further, you can reload your application with new code gracefully, while nginx stays up and Unicorn swaps out backend quietly.
I recently deployed an app and am using WEBrick, and was considering on switching to Thin. I am wondering on the different options that exist and are best for a heroku environment?
Thanks.
Provided you're on Cedar stack you can use whatever you want - Thin works, you are able to get excellent performance out of Unicorn though on Heroku - http://blog.railsonfire.com/2012/05/06/Unicorn-on-Heroku.html
(Asummption: You don't mean WEB server (i.e Apache or Nginx), but your application process)
The only real constraint is what you can run on Linux. Nginx is the proxy that is used by the Heroku stack - but behind that it's up to you.
I've seen stuff running Thin, Webrick and Unicorn with no problems.