I recently discovered this line in my Gemfile:
# Use unicorn as the app server
# gem 'unicorn'
I have 2 questions.
Why would I want to use unicorn over the default WEBrick?
How do I get it to work? I uncommented that line, ran bundle install and then rails server and it still booted up WEBrick
Reasons why you would use Unicorn instead of WEBrick?
Unicorn is supposed to be faster than WEBrick
You can spawn multiple processes
If you are using unicorn in production. You would want your development env to be as close as production.
How to run unicorn locally?
Uncomment gem 'unicorn' in Gemfile
Create unicorn.rb file in config/ and add the following line. You can increase the number of processes if you want to
worker_processes 1
start unicorn using the following command
unicorn -c config/unicorn.rb
While this is mostly an opinion answer, Unicorn supports multiple "worker" processes to handle concurrent web requests by executing one instance of Unicorn. The number of worker processes you can run depends on the specs of the hardware, but generally 3-4 workers is safe for small servers and even development machines. You'd need multiple WEBrick processes for concurrent requests. I've also found Unicorn to be faster than WEBrick, especially in production applications and apps running on Heroku. Heroku actually has some really good documentation on this that is applicable outside of Heroku as well.
Take a look at the Unicorn gem documentation as well as the Heroku docs above. TL;DR - you'll use the command unicorn instead of rails server to run your app using Unicorn.
You can also use the unicorn_rails gem which will override default webrick and unicorn instead
https://github.com/samuelkadolph/unicorn-rails
Related
I am using private_pub gem for live chat in my rails 3.2 application and it is working perfectly on development mode but I am stuck at how to do it on production.
I am using apache2 in production. When I ran this command on server
RAILS_ENV=production bundle exec rackup private_pub.ru -s thin -E production
It starts the thin server but my app keeps on waiting for response from
http://www.example.com:9292/faye.js
It doesn't do anything. I am unable to connect with faye in prodution
Thanks for help in advance
Thin and Apache need to be set up running on different ports.
The default settings for both should work, but you should double
check. Ensure apache is running under port 80 and thin is using port
9292. These numbers should be visible when the servers start up.
In the end you should be able to access faye.js at
http://yoursite.com:9292/faye.js and your site at http://yoursite.com/
Source: https://stackoverflow.com/a/6667347/539075
I use on heroku unicorn , Procfile is already used by Heroku for unicorn server. I would like on development use gem foreman , is it possible to configure gem use different file than Procfile??
foreman start --procfile myfile
or
foreman start -f myfile
That being said, the whole idea of foreman and Procfiles is to use the same one everywhere so you can keep your development environment as close as possible to your production environment.
I would recommend looking at the docs here and making sure you really need a whole separate file for development.
New to Rails and very new to Delayed Jobs.
Got one that's supposed to be triggered after 5 minutes. I finally got it to work so that if I run
rake jobs:work
in my terminal, the job starts up and works correctly. If I CTRL-C and exit that action in my terminal, the delayed job stops working correctly. This is one thing on my local server and another on Heroku, where I have to start up the delayed job using
heroku run rake jobs:work
I looked into the new Heroku toolbelt and downloaded the gem they suggest for worker maintenance, foreman, but when I run "foreman start", I get this error
ERROR: procfile does not exist
I don't know what a procfile is, I'm afraid of breaking things after spending pretty much a day debugging my delayed_jobs actions, and I want to do this right to make sure it works instead of figuring out some hacky fix that breaks down later -- so I figured I should ask this question, however obnoxiously vague it may be.
Should I be using foreman for this? Or workless? (Saw that in another SO question). Where's my procfile? Should I do anything with it?
Thanks,
Sasha
You should be using a procfile to set up your Heroku processes, this is the standard method that Heroku uses to define and control the processes.
If you haven't utilised a procfile to this point everything will probably still work as Heroku adds some default processes when you push a Rails app, including both the web and worker processes. The default worker process is set to delayed job.
Foreman was developed in order to set up your local machine to use the same approach but, unlike the Heroku service, Foreman actually requires a procfile to be present to control the services that are started when Foreman is started as it doesn't know how to setup defaults.
I would suggest creating a procfile, placed in the root directory of your project, to ensure that your processes are set up and operating in the same manner on your local machine as on Heroku. If you want to mimic what Heroku sets up automatically you add the following to the procfile depending on whether you are using the Thin web server (which Heroku recommends) or not.
With Thin in your gemfile:
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
worker: bundle exec rake jobs:work
Without a special web server (eg you are using webrick, the rails default):
web: bundle exec rails server -p $PORT
worker: bundle exec rake jobs:work
Once this file is in place you can run foreman on your local machine and it will start your web server and delayed_job workers automatically.
Running through this process will only impact starting delayed_job on the local machine. As you are running the exact same command bundle exec rake jobs:work as you are currently using there should be no impact on your dj actions in either locally or on Heroku. Obviously some testing is required to make suer this is actually the case.
Workless is designed to scale workers on Heroku so that you don't have to pay for them when there is no work available. It has no bearing on the procfile or defining how to actually start a dj worker process.
as far as I know, there are 2 version of delayed_job:
original(tobi's) https://github.com/tobi/delayed_job
collectiveidea's fork: https://github.com/collectiveidea/delayed_job
when using the collectiveidea version, you should start it as below:
# Runs two workers in separate processes.
$ RAILS_ENV=production script/delayed_job -n 2 start
I am not familiar with delayed_job on Heroku, please follow its instructions.
Here's what my Procfile looks like:
web: bundle exec rails server thin -p $PORT -e $RACK_ENV
worker: bundle exec rake jobs:work
I intend to add a worker process because I wish to run some background jobs. I'm following these instructions
This is what I noticed:
No problems encountered if the worker is started separately.
When I keep the second line in the Procfile and don't not change anything else, the rails server serves a couple of requests and hangs after that
As mentioned here , I've added STDOUT.sync = true to config/environments/development.rb and verified the same in the rails console. Did not work.
Tailed log/development.log and compared it against the stuff that foreman outputted to the shell and noticed that both matched for a couple of requests and then foreman stopped printing out stuff to the shell - the next request would then hang
I updated foreman using foreman.pkg as mentioned here and verified the same with [6]
It was mentioned here that this might be caused due to a stray debug statement. I'm not using the debugger and I do not have the pry gem or the ruby-debug gem in my Gemfile.lock
I believe the symptoms are similar to this related unanswered question
Please help!
[6]:
which foreman
/usr/bin/foreman
ls -lah /usr/bin/foreman # checked the updated date
Tracked and resolved here:
https://github.com/ddollar/foreman/issues/244
TL;DR: Install the gem, don't use foreman.pkg
I'll add than if you're using Heroku, the foreman version included with the heroku toolbelt has the same issue.
Use the one you can get with gem install foreman instead.
The only difference I've noted is that rails server starts the server on port 3000, while rackup starts the server on port 9292.
Are there any other differences?
Are there use cases for one instead of the other?
rails server is the command for starting your server (usually WEBrick) and is in rails.
rackup is a command that comes with the rack middle and uses the settings in your config.ru and starts a server based off of those. This is a standard (it will work for other frameworks and rack-based applications) and is usually used in production servers.
One difference of note is that if you start a server with rails s then you will see the output in the terminal.
In my experience, in production, rackup is used by phusion passenger so you wouldn't want rails s in that situation.
As an aside, the port can be changed with both rails server and rackup using the -p flag.