в чем преимущество EventMachine - PullRequest
2 голосов
/ 29 апреля 2011

Это мой тестовый пример, я обнаружил, что EM не быстрее, чем обычный TCP-сервер

EM-сервер:

    require 'rubygems'
    require 'benchmark'
    require 'eventmachine'
    class Handler  < EventMachine::Connection
      def receive_data(data)
            operation = proc do
                # simulate a long running request
                 a = []
                n = 5000
                for i in 1..n
                    a << rand(n)
                    a.sort!
                end
            end

        # Callback block to execute once the request is fulfilled
        callback = proc do |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..."
    }

и мой тест производительности:

require 'rubygems'
require 'benchmark'
require 'socket'
Benchmark.bm do |x|
    x.report("times:") do
        for i in 1..20
            TCPSocket.open "127.0.0.1", 8080 do |s|
                    s.send "#{i}th sending\n", 0    
                if line = s.gets
                    puts line
                end
                puts "#{i}th sending"
            end
        end
    end
end

Ответы [ 3 ]

3 голосов
/ 29 апреля 2011

Простота по сравнению с потоками, а не скорость. Более подробную информацию можно найти здесь: EventMachine: быстрая и масштабируемая управляемая событиями платформа ввода-вывода

Цитата, которая относится к вашему вопросу:

Много было написано о том, что управляемые событиями программы теоретически не быстрее, чем многопоточные, и это правда. Но на практике я думаю, что с моделью, управляемой событиями, легче работать, если вы хотите достичь чрезвычайно высокой масштабируемости и производительности, при этом обеспечивая максимальную надежность. Я пишу программы, которые должны работать месяцами или годами без сбоев, утечек памяти или каких-либо проблем с производительностью, поэтому на практике программирование на основе событий работает лучше. Теперь проблема в программировании на основе событий: вы должны писать «назад». Потоковая модель хранит состояние вашей программы (неэффективно) в локальных переменных в стеке времени выполнения. В EM вы должны делать это самостоятельно, что не очень понятно программистам, привыкшим к потокам. Вот почему я заинтересован в волокнах, потому что это открывает возможность писать то, что выглядит для программиста как блокировка ввода / вывода, но все еще выравнивается и не использует потоков.

1 голос
/ 29 апреля 2011

Мы только что прошли это упражнение в нашем проекте вчера. Концептуальных препятствий предостаточно.

Взгляните на это демо рельсовое приложение от Ильи Григорика. Он использует Apache Benchmark для одновременного подключения к серверу, как если бы вы получали трафик от нескольких посетителей на ваш сайт. Здесь вы получаете преимущество от Eventmachine. Вместо того, чтобы все вызовы в базе данных выстраивались друг в друга, они отправляются асинхронно, и результаты впечатляют. Если вы установите демо, вы увидите разницу, заменив адаптер em_mysql2 (быстрый) на адаптер mysql2 (медленный) в database.yml

Аналогичным образом, если вы нажмете на Eventmachine в цикле, вы ограничены синхронной природой самого цикла (медленно).

0 голосов
/ 13 марта 2014

Одно - вы должны вызвать EM.epoll перед тем, как войти в цикл обработки событий с EM.run, а не внутри него.

EventMachine.epoll
EventMachine::run {
  EventMachine::start_server("0.0.0.0", 8080, Handler)
  puts "Listening..."
}
...