ruby - what is the advantage of EventMachine -
this test case, found em not faster general tcp server
the em server:
require 'rubygems' require 'benchmark' require 'eventmachine' class handler < eventmachine::connection def receive_data(data) operation = proc # simulate long running request = [] n = 5000 in 1..n << rand(n) a.sort! end end # callback block execute once request fulfilled callback = proc |res| send_data "send_response\n" end puts data em.defer(operation, callback) end end eventmachine::run { eventmachine.epoll eventmachine::start_server("0.0.0.0", 8080, handler) puts "listening..." }
and benchmark test:
require 'rubygems' require 'benchmark' require 'socket' benchmark.bm |x| x.report("times:") in 1..20 tcpsocket.open "127.0.0.1", 8080 |s| s.send "#{i}th sending\n", 0 if line = s.gets puts line end puts "#{i}th sending" end end end end
simplicity compared threads, not speed. here more insights: eventmachine: fast , scalable event-driven i/o framework
the citation applies question:
a lot has been written fact event-driven programs not theoretically faster threaded ones, , true. in practice, think event-driven model easier work with, if want extremely high scalability , performance while still ensuring maximum robustness. write programs have run months or years without crashing, leaking memory, or exhibiting kind of lumpy performance, in practice, event-driven programming works better. now, here's problem event-driven programming: have write "backwards." threaded model stores program state (inefficiently) in local variables on runtime stack. in em have yourself, unintuitive programmers used threads. why i'm interested in fibers, because opens possibility of writing looks programmer blocking i/o, still evented , uses no threads.
Comments
Post a Comment