Configuration Unicorn over nginx

Nginx Using Rails

Introduction

Nginx is an open source reverse proxy server for HTTP, HTTPS, SMTP, POP3, and IMAP protocols, as well as a load balancer, HTTP cache, and a web server.

How it works

Nginx works on event driven architecture. it means that notifications or signals are used to mark the initiation or completion of a process. Thus, the resources can be used by other process until a process initiation event is triggered and resource can be allocated and released dynamically. This leads to the optimized use of memory and CPU. Nginx doesn’t create a new process for a new request.

Nginx has one master process and several worker processes. The main purpose of the master process is to read and evaluate configuration, and maintain worker processes. Worker processes do actual processing of requests. nginx has focused on high performance, high concurrency and low memory usage.

Configuration

Unicorn

Write the following code on your local machine config/unicorn.rb

listen "127.0.0.1:8080"

worker_processes 4

preload_app true

user 'vagrant'

root = "/home/vagrant/app/sample_app/current"

working_directory root

pid "#{root}/tmp/pids/unicorn.pid"

stderr_path "#{root}/log/unicorn.log"

stdout_path "#{root}/log/unicorn.log"

# listen "/tmp/unicorn.sample_app.sock"

timeout 30

user: set user name of the server.

working_directory: path to the application.

listen: Url which will communicate with nginx.

Nginx Configuration:

On server machine, open `vi /etc/nginx/nginx.conf` and paste the below code.

worker_processes 1;

user vagrant;

pid /tmp/nginx.pid;

error_log /home/vagrant/app/sample_app/shared/log/nginx.error.log;

events {

  worker_connections 1024; # increase if you have lots of clients

  accept_mutex off; # "on" if nginx worker_processes > 1

}

http {

  include mime.types;

  default_type application/octet-stream;

  access_log  /home/vagrant/app/sample_app/shared/log/nginx.access.log combined;

  sendfile on;

  tcp_nopush on; # off may be better for *some* Comet/long-poll stuff

  tcp_nodelay off; # on may be better for some Comet/long-poll stuff

  upstream app_server {

    server 127.0.0.1:8080;

  }

  server {

    client_max_body_size 4G;

    server_name localhost;

    keepalive_timeout 600s;

    root /home/vagrant/app/sample_app/current;

    try_files $uri/index.html $uri.html $uri @app;

    location @app {

      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      proxy_set_header Host $http_host;

      proxy_redirect off;

      proxy_pass http://app_server;

    }

    # Rails error pages

    error_page 500 502 503 504 /500.html;

    location = /500.html {

      root /home/vagrant/app/sample_app/current;

    }

  }

}

   `upstream` should have the IP or path that is given in unicorn `listen`.

Unicorn Vs Phusion Passenger

Unicorn vs Phusion Passenger

Unicorn :- Unicorn is a Rack HTTP server that uses forked processes to handle multiple incoming requests concurrently. Unicorn is an HTTP server for Rack applications designed to only serve fast clients on low-latency, high-bandwidth connections and take advantage of features in Unix/Unix-like kernels. Slow clients should only be served by placing a reverse proxy capable of fully buffering both the the request and response in between Unicorn and slow clients.

Phusion Passenger :- Phusion Passenger is an application server which can directly integrate into Apache. It is designed to be easy to use, fast, stable and reliable. Phusion Passenger is a so-called polyglot application server because it supports applications written in multiple programming languages. At this time, Ruby and Python are supported.

Difference

Note: Neither Unicorn nor Phusion Passenger support Windows. Both of them require a Unix OS.

Unicorn and Phusion Passenger are both application servers that support Ruby. Although they share similar basic features, there are large differences in how they approach usage, and large differences in technical decisions.

Phusion Passenger is a polyglot, multi-application server. It supports  Python,  Node.js  and  Meteor.

Unicorn is Ruby-only.

Unicorn does not support JRuby and Rubinius, while Phusion Passenger does.

Ease of use

Phusion Passenger requires less system administration knowledge, is easier to setup and requires less human management.

Unicorn acts more like a specialized component that you have to integrate in a larger system. Using Unicorn requires more system administration knowledge and skills.

 Scalability

Both Unicorn and Phusion Passenger can be scaled easily, through the use of HTTP load balancing tools and reverse proxies such as HAProxy and Nginx. Both of them support both inter-server scalability (scaling to multiple servers) as well as intra-server scalability (scaling within a server, on the process level) .

Concurrency

Both Unicorn, as well as the open source variant of Phusion Passenger, are multi-process single-threaded. The Enterprise variant can be configured to be either single-threaded or multithreaded.

Multithreading allows less memory usage and provides higher concurrency than multi-process single-threading. Multithreading is especially suitable for applications that require high I/O concurrency, e.g. applications that perform a lot of HTTP API calls or otherwise block on I/O, or applications which serve WebSockets.

Phusion Passenger Enterprise can be hybrid multi-process multi-threaded. That is, running multiple multithreaded processes. Hybrid mode allows Ruby and Python, which despite having a Global Interpreter Lock, to fully utilize all CPU cores.

Performance

Performance characteristics depends on the workload, so this should be explained in two parts.

CPU-bound, fast requests

For CPU-bound, fast requests that don't involve blocking I/O, Unicorn and Phusion Passenger (both the open source and Enterprise variant) perform similarly in production, but differently in microbenchmarks.

In microbenchmarks Unicorn is faster because in Phusion Passenger, all data goes through an additional process, the PassengerHelperAgent, which sanitizes request headers, coordinates process spawning, collects statistics, etc. The overhead is not big, approximately a little more than an extra read()/write() call to the kernel. The difference is almost unnoticable when benchmarking over the network. But in local machine microbenchmarks where you are benchmarking how quickly the app can do nothing, Phusion Passenger will appear to be twice as slow because of the extra proxy layer. On the other hand, that extra proxy layer is what allows us to provide accurate statistics and to implement robust process coordination, so it's not there for nothing. We do have some ideas on how to address even this in the future.

I/O-bound, slow requests

For slow requests that are bound by blocking I/O, Unicorn and the open source version of Phusion Passenger perform similarly, thanks to their identical I/O concurrency models.

Phusion Passenger Enterprise achieves higher concurrency than both Unicorn and the open source version of Phusion Passenger, thanks to support for multithreading.

Security

Phusion Passenger has a builtin security sandboxing feature.

Sandboxing allows one to run different applications in different sandboxes, so that if one application has a security vulnerability, its damage has a lower chance of spreading to other applications on the same system. This implemented by using operating system user account privilege separation features.

Phusion Passenger has I/O safety features built in, and does not require extra integration with a buffering reverse proxy.

Phusion Passenger in its Standalone mode can also be directly exposed to the Internet, so that it can be used with minimal setup time.

Unicorn does not provide any builtin sandbox features. It is possible to run Unicorn in a sandbox, but that is something the system administrator has to manually setup.

Unicorn also lacks certain I/O safety features.

Unicorn cannot be safely exposed to "slow clients" or internet, and must therefore be installed behind a buffering reverse proxy, e.g. Nginx. This is why Unicorn is only ever used together with Nginx, and cannot be directly exposed to the Internet by itself

Multitenancy

Phusion Passenger is designed for multitenant (multi-app) deployment by default. This shows in both usage and the management tools. With a single Phusion Passenger install, you can easily deploy multiple apps. With a single set of management tools, you can manage all your apps.

With Unicorn, you have to manage each app individually.

Management tools

Unicorn provides some management tools which allow you to stop or restart Unicorn and to query its status. The tooling is minimalistic, and provides limited information, though the information that is available is very useful.

Phusion Passenger provides management tools that provide much more insight. Phusion Passenger allows you to stop, restart and to query its status through command line tools like passenger-status, passenger-config, passenger-memory-stats. These tools are regular command line tools.

These tools display everything Unicorn's tools display, plus the exact requests that are currently running, how long they've been running, the application's CPU and memory usage, etc.

Debugging and inspection

The open source version provides tools for debugging stuck applications by displaying all threads' backtraces, while Unicorn does not appear to have such functionality. Phusion Passenger Enterprise provides a live IRB console that you can attach to any live, running process for inspection. It also provides ruby-debug integration that you can use even in multi-process mode.

Config Amazon SES In ROR

Amazon SES

Amazon Simple Email Service (Amazon SES) is a cost-effective outbound-only email-sending service built on the reliable and scalable infrastructure that Amazon.com has developed to serve its own customer base. With Amazon SES, you can send transactional email, marketing messages, or any other type of high-quality content and you only pay for what you use.

Along with high deliver-ability, Amazon SES provides easy, real-time access to your sending statistics and built-in notifications for bounces and complaints to help you fine-tune your email-sending strategy.

Steps to set up Amazon SES in rails:-

1. Make an account on amazon services. www.amazon.com

2. Go to the link

https://console.aws.amazon.com/ses/home#smtp-settings:

and click on button “create my smtp creds” and it will return a username and password

which we will use in our smtp settings

3. Now in config/applicaiton.rb

config.action_mailer.delivery_method = :smtp

config.action_mailer.default_url_options = { :host => 'localhost:3000'}

config.action_mailer.smtp_settings = {

:address => 'email-smtp.us-east-1.amazonaws.com',

:port => '25',

:domain => 'localhost:3000', # Your domain

:user_name => '************************’',

:password => '******************************************',

:authentication => :login,

:enable_starttls_auto => true

}

Domain will be changed according the server(like for production environment it will be production URL).

4. And we will start sending email,

The ‘Sender’ person should be verified by aws-ses.

and The user from in application will be the verified user.

https://console.aws.amazon.com/ses/home#verified-senders-email:

5. The email sending procedure will be same as we use default behavior of action mailer but now the email will sent using Amazon SES.