WEB SERVER CHALLENGE a compass in Ruby on Rails servers jungle 1 rubyday 2014

who we are a short presentation Filippo gangi dino Frontend & Rails developer alessandro fazzi Sysadmin & Rails developer 2

we work with our agencies Turin Milan 3

the challenge start 4

Agenda why? What? how? about this f**king talk the challengers hands-on 1. 2. 4. 5 WhEN? use cases 3.

Why? about this f**king talk 6

why? We are developers.! We are not sysadmins (not everyone).! We are in ease to build our conventions.! Our customers have their conventions. ! We have to fight the habit. fight the habit! about this f**king talk 7

why? different applications different needs about this f**king talk 8

why? In 1827* Ruby didn’t run on any server.! In 1996* Ruby run only with CGI.**! To answer to different needs TODAY there’s a wide offer.! wide offer about this f**king talk 9 *Unverified sources! **http://ruby-doc.com/docs/ProgrammingRuby/html/web.html

what? the challengers 10

what? the challengers thin one socket for everyone unicorn one master process to rule them all passenger keep calm and serve web pages puma multithread agility 11

General Concepts A process is an instance of an application that is being executed. It contains the program code and its current activity. Depending on the operating system, a process may be made up of multiple threads of execution that execute instructions concurrently. process / worker Glossary 12 https://en.wikipedia.org/wiki/Process_(computing)

General Concepts A thread of execution is the smallest sequence of programmed instructions that can be managed independently by a scheduler. […] in most cases, a thread is a component of a process. Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources. Thread Glossary 13 https://en.wikipedia.org/wiki/Thread_(computing)

General Concepts A Unix domain socket is a data communications endpoint for exchanging data between processes executing within the same host operating system. ! The API for Unix domain sockets is similar to that of an Internet socket, but it does not use an underlying network protocol for communication. *! ! A network socket is an endpoint of an inter-process communication flow across a computer network. Today, most communication between computers is based on the Internet Protocol; therefore most network sockets are Internet sockets. ** Socket Glossary 14 * https://en.wikipedia.org/wiki/Unix_domain_socket! ** https://en.wikipedia.org/wiki/Network_socket

15 Multiple workers each with its own socket thin one socket for everyone Cluster Mongrel parser: the root of Mongrel speed and security HTTP Deploys with hot restart using the one-by-one option 0 Downtime Processes take action only when an event fires Event-machine No master controlling process No master

16 Every worker will pull data from a unique socket, individually Unicorn one master process to rule them all balance Mongrel parser: the root of Mongrel speed and security HTTP The newly created master process will kill the old one 0 Downtime If any worker becomes unresponsive, the master kills it and fork itself again patricide One master process controls workers’ lifecycle master

17 It runs inside your good old web server passenger keep calm and serve web pages integrated It works well with default options, most of the time out of the box Enterprise version and support enterprise

The only challenger actually using multithread approach puma multithread agility multithread Real concurrency (if your Ruby implementation allows) concurrency Parser inherited from Mongrel http THE server for Rubinius and JRuby Ruby implementation Rubinius/jruby Deploys with hot restart using the one-by-one option 0 Downtime

when? use cases 19

when? Best suited to a single application running at all times on a given host.! It runs based on EventMachine meaning that may benefit applications with an event-based architecture, for example long-polling applications. thin use cases 20

when? Built to cut off long running worker processes.! Best suited with one application on a host, it will spawn several workers and maintain them at all times.! Memory consumption could be a problem.! Fast client!! Not best suited for long running requests, large upload, etc. unicorn use cases 21

when? Elastic and automatic memory management. It kills zero traffic workers and dynamically respawn them as needed.! Best suited for more applications on the same hardware, so long as their traffic is minimal and the application is small enough to relaunch quickly when Passenger needs.! You do not need additional sysadmin knowledges out of how to make your Apache/nginx web server work passenger use cases 22

when? Is threaded and it can benefit more from JRuby or Rubinius (no Global Virtual machine interpreter Lock).! Puma will request a new thread from the system for each incoming request, so if you need multithread in your app, go with it!! Best suited with multi-core hardware and for external requests to databases, APIs, I/O blocking requests, etc. puma use cases 23

how? hands-on 24

how? PI: Computes pi to 5,000 decimal places.! ! Server: Spits out informations about the application server itself.! ! Sleep: Sleep for 1 second and then returns a response.! ! Random: Does one of the above at random. a handful of tests hands-on 25 stolen from the internet! siege -r 1000 -c 100 -b -q http://example.com w/ this kind of load

trasnactions/sec PI Server (x10) Sleep Random 26,6 31,3 31,9 8,6 19,0 6,0 35,3 8,8 23,7 6,0 32,2 11,9 11,6 0,2 34,4 11,6 Thin Unicorn Passenger Puma numbers! Transaction rates per second 26 https://github.com/jaustinhughey/app-server-arena/tree/master/performance ! ! ! ! ! ! Test failed before completion

how? hands-on 27 if you’d like to try

thin hands-on 28 gem install thin ! cd to/your/app single upstream thin_cluster { server unix:/tmp/thin.escolinhas.0.sock; server unix:/tmp/thin.escolinhas.1.sock; server unix:/tmp/thin.escolinhas.2.sock; server unix:/tmp/thin.escolinhas.3.sock; } clustered thin start -s 4 behind nginx behind apache w/ mod_proxy_balanceer BalancerMember http://127.0.0.1:5000 BalancerMember http://127.0.0.1:5001 BalancerMember http://127.0.0.1:5002 BalancerMember http://127.0.0.1:5003 ProxyPass / balancer://thinservers/ ProxyPassReverse / balancer://thinservers/ ProxyPreserveHost on gem ‘thin’ add to your gem file run it thin start

unicorn hands-on 29 29 gem install unicorn ! cd to/your/app ! unicorn_rails single clustered gem install unicorn ! cd to/your/app echo "worker_processes 3" > config/myconf ! unicorn_rails -c config/myconf tune it

passenger hands-on 30 gem install passenger ! cd to/your/app ! passenger start -R config.ru stand alone or If you are on a mac brew install passenger ! cd to/your/app ! passenger start -R config.ru with apache or nginx Eeerrrr…well this is a complicated task to be constrained in half a slide. Let’s just talk about it a minute :)

puma hands-on 31 gem install puma ! cd to/your/app gem ‘puma’ add to your gem file run it rails s puma tune it # config/puma.rb threads 8,32 workers 3 preload_app! single clustered gem install puma ! cd to/your/app gem ‘puma’ add to your gem file puma -C config/puma.rb run it

32 Questions? make it now! dev.welaika.com! cayenne.it Twitter @mukkoo! @Pioneer_Skies

Thanks to all* 33 * special thanks to J. Austin Hughey - Engine Yard for his great article