Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Web server challange - RubyDay IT 2014

weLaika
September 26, 2014

Web server challange - RubyDay IT 2014

The question about the choice of the best web server for our Ruby/RoR applications is common in a developer's day life.
We'll spot features, similarities and moreover differences between most used web servers.
We'll try to give a compass in order to find the right way for any single project needs.

weLaika

September 26, 2014
Tweet

More Decks by weLaika

Other Decks in Programming

Transcript

  1. who we are a short presentation Filippo gangi dino Frontend

    & Rails developer alessandro fazzi Sysadmin & Rails developer 2
  2. 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
  3. 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
  4. 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
  5. 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)
  6. 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)
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. 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
  18. 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 <Proxy balancer://thinservers> 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 </Proxy> ProxyPass / balancer://thinservers/ ProxyPassReverse / balancer://thinservers/ ProxyPreserveHost on gem ‘thin’ add to your gem file run it thin start
  19. 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
  20. 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 :)
  21. 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
  22. Thanks to all* 33 * special thanks to J. Austin

    Hughey - Engine Yard for his great article