[Moscow.pm] Moscow.pm party: доклад-реквесты

[Mons Anderson]

On 22.11.2013, at 21:24, Андрей П. Ковбович <akovbovich на gmail.com> wrote:

> Тут прозвучал вопрос про некие узкоспециализированные решения, где асинхронная модель не подходит. Я так понимаю это случай, когда требуется строго последовательная обработка. Например, аукцион, когда нужно сматчить биды с асками в режиме fifo.
> 

Нет, я не такой случай имел в виду.
Алгоритмически асинхронное приложение не отличается от синхронного. т.е. там точно так-же можно выстроить строго последовательную обработку.

Пример, который я имел в виду:
Писал я UDP сервер. Мне нужно было проверить предельную нагрузку. Я сделал клиент, который заваливал интерфейс UDP пакетами.
Написал асинхронный udp сервер на perl/EV. мало пакетов при 100% CPU.
Написал аналогичный сервер на C/libev. Прирост 10-20%, 100% CPU.
Написал синхронный сервер на Pure Perl. Прирост 400%.

Ситуация оказалась довольно простая: в синхронном варианте всё, что делает сервер - это вызывает в цикле recv, тогда как в асинхронном почти на каждый пришедший пакет вызывается on_read watcher.

Решилось довольно просто.
SO_RECVBUF был поднят до нескольких мегабайт, а после прочтения пакетов из сокета следующий on_read ставился не сразу, а через 0.0001s.
После этого изменения на каждый on_read мы вычитывали не 1-2 пакета, а, в зависимости от значения таймера, от 10 до 1000 пакетов за 1 раз.

соответственно оверхед от ev был сведен к процентам и производительность получилось почти такая, как у синхронного варианта.

PS: Perl/EV на 1 core при 100% загрузке CPU в пределе может обработать около 450-500k udp pkt/s


----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20131123/b7ee7021/attachment-0001.html>