Понимание параллельного программирования с Руби Голиафом

PostRank недавно выпустил новый веб-сервер Ruby: Goliath . Он использует цикл обработки событий таким же образом, как node.js и nginx для достижения высокого уровня параллелизма, но добавляет некоторый специальный соус, который позволяет традиционно сложному асинхронному коду быть написанным в синхронном стиле.

Например, асинхронный код на Ruby обычно выглядит следующим образом (с использованием библиотеки событий машины):

require 'eventmachine' require 'em-http' EM.run { EM::HttpRequest.new('http://www.sitepoint.com/').get.callback {|http| puts http.response } } 

Это удобно тем, что позволяет приложению выполнять другие действия, пока HTTP-запрос завершается (это «неблокирующий»), но для последовательного извлечения двух сайтов вам необходимо вложить обратные вызовы:

 EM::HttpRequest.new('http://www.sitepoint.com/').get.callback {|http| # extract_next_url is a fake method, you get the idea url = extract_next_url(http.response) EM::HttpRequest.new(url).get.callback {|http2| puts http2.response } } 

Как вы можете себе представить, эта модель быстро становится грязной. Голиаф позволяет нам писать вышеуказанный код простым синхронным способом, с которым мы знакомы:

 http = EM::HttpRequest.new("http://www.sitepoint.com").get # extract_next_url is a fake method, you get the idea url = extract_next_url(http.response) http2 = EM::HttpRequest.new(url).get 

… все же за кадром это все еще выполняется асинхронно! Другой код может быть запущен во время выполнения HTTP-запросов.

Это поражает меня. Как это работает? Давай выясним.

Волокна

Исходя из документации , Голиаф утверждает, что творит свое волшебство, «используя волокна Ruby, представленные в Ruby 1.9+». Этот первый намек отправляет нас в ruby rdocs, чтобы найти:

Волокна — это примитивы для реализации облегченного совместного параллелизма в Ruby. По сути, они являются средством создания блоков кода, которые можно приостанавливать и возобновлять, подобно потокам. Основное отличие состоит в том, что они никогда не выгружаются и что планирование должно выполняться программистом, а не виртуальной машиной.

Ух, слишком много громких слов. Давайте просто погрузимся и начнем изучать код Голиафа. Документация Goliath содержит полный пример прокси сайта:

 require 'goliath' require 'em-synchrony' require 'em-synchrony/em-http' class HelloWorld < Goliath::API def response(env) req = EM::HttpRequest.new("http://www.google.com/").get resp = req.response [200, {}, resp] end end # to play along at home: # $ gem install goliath # $ gem install em-http-request --pre # $ ruby hello_world.rb -sv 

Мы знаем, что для того, чтобы это происходило асинхронно, в этом вызове #get должно происходить какое-то забавное дело, поэтому давайте попробуем найти это. Мое чувство паука говорит мне, что это будет где-то в em-synchrony/em-http …

 $ gem unpack em-synchrony Unpacked gem: '/Users/xavier/Code/tmp/em-synchrony-0.3.0.beta.1' $ cd em-synchrony-0.3.0.beta.1 # I used tab completion on the next line to find the exact path $ cat lib/em-synchrony/em-http.rb 

Это показывает:

 # em-synchrony/lib/em-synchrony/em-http.rb begin require "em-http" rescue LoadError =< error raise "Missing EM-Synchrony dependency: gem install em-http-request" end module EventMachine module HTTPMethods %w[get head post delete put].each do |type| class_eval %[ alias :a#{type} :#{type} def #{type}(options = {}, &amp;blk) f = Fiber.current conn = setup_request(:#{type}, options, &amp;blk) conn.callback { f.resume(conn) } conn.errback { f.resume(conn) } Fiber.yield end ] end end end 

Джек-пот! Волокна! Похоже, что это патча для существующей библиотеки em-http , поэтому прежде чем мы зайдем слишком далеко, давайте выясним, как выглядит обычный код em-http без волокон. В вики em-http-request есть удобный пример:

 EventMachine.run { http = EventMachine::HttpRequest.new('http://google.com/').get :query =< {'keyname' =< 'value'} http.errback { p 'Uh oh'; EM.stop } http.callback { p http.response_header.status p http.response_header p http.response EventMachine.stop } } 

Это выглядит почти так же, как и в приведенном выше коде, который является многообещающим, и когда мы углубимся в это, это станет еще более очевидным.

 $ gem unpack em-http ERROR: While executing gem ... (Gem::RemoteFetcher::FetchError) SocketError: getaddrinfo: nodename nor servname provided, or not known (http://rubygems.org/latest_specs.4.8.gz) # Oh noes it doesn't work! # Search for em gems $ gem list em- *** LOCAL GEMS *** em-http-request (1.0.0.beta.2, 0.3.0) em-socksify (0.1.0) em-synchrony (0.3.0.beta.1) $ gem unpack em-http-request # Ah that is probably it $ cd em-http-request-1.0.0.beta.2 $ ack "get" lib/ lib/em-http/http_connection.rb 4: def get options = {}, &blk; setup_request(:get, options, &blk); end 

Обратите внимание на последнюю строку, которая get откладывает прямо на setup_request , который является тем же самым вызовом, который сделан в примере волокна выше. Да, почти так же. Теперь мы можем вернуться к оптоволоконному коду.

 f = Fiber.current conn = setup_request(:#{type}, options, &blk) conn.callback { f.resume(conn) } conn.errback { f.resume(conn) } Fiber.yield 

 class Surprise < Goliath::API def response(env) sleep 1 [200, {}, "Surprise!"] end end 

 $ ab -n 3 -c 3 127.0.0.1:9000/ | grep "Time taken" Time taken for tests: 3.011 seconds 

 class Surprise < Goliath::API def response(env) EventMachine.add_timer 1, proc { [200, {}, "Surprise!"] } end end 

 class Surprise < Goliath::API def response(env) f = Fiber.current EventMachine.add_timer 1, proc { f.resume } Fiber.yield [200, {}, "Surprise!"] end end 

 $ ab -n 3 -c 3 127.0.0.1:9000/ | grep "Time taken" Time taken for tests: 1.009 seconds