web server/framework + amqp (2)

rainbows! 測完了，正常運作。

跑 RabbitMQ
> sudo rabbitmq-server

寫 rainbows config
> cat rainbows.rb

worker_processes 4 # assuming four CPU cores
Rainbows! do
  use :EventMachine
  worker_connections 100
end

寫 rack config
> cat config.ru

require 'mq'
AMQP.settings.merge!(:host => 'localhost', :port => 5678)
use ContentLength
run lambda{ |env|
  MQ.new.queue('one').publish('ping!')
  [200, {'Content-Type' => 'text/plain'}, ["ok\n"]]
}

去 amqp 的 example 中挖出 pingpong.rb,
把 EM.add_periodic_timer(1){ 那段全部註解掉。
這樣才不會被他的 ping/pong 一直洗板。
跑 pingpong.rb
> ruby pingpong.rb

跑 rainbows:
> rainbows -c rainbows.rb

爬爬看結果如何
> curl :8080

接著應該就可以在 ruby pingpong.rb 那個畫面上看到 ping!/pong

結論是 amqp gem 確實很聰明，只要是在 eventmachine 的
event loop 裡面，想做什麼就做什麼。
本來還在想最壞的打算是把 EM.run 那行改掉... 看來是不用了。

==
這樣還要測 bunny 嗎？用 rainbows 的缺點是，
原本用 nginx + unicorn 的效能應該會比較好。
多包了 rainbows 其實是有點多餘。不過多餘的前提是，
每個 action 都很快。如果有很慢的 action...
那 rainbows 還是需要的。

官方建議是，nginx => unicorn + rainbows.
也就是說反應快速的直接丟給 unicorn,
而比方說上傳縮圖之類的那種，就丟給 rainbows.

這樣分其實也滿麻煩的...
但如果真的有那種 spike, 這樣會穩得多。
這其實也有點像是 passenger 裡面打開 global queue.