[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

> 
> пятница, 22 ноября 2013 г. пользователь Анатолий Гришаев <0body0 на rambler.ru> писал:
> Мне показалось, что нет.
> А до этого в переписке было аналогичное решение твоему решение.
> 
> И ksvs не написал, чем закончилось, и может и твоё решение не подошло.
> Хотел знать из первых рук, чего было и чем закончилось.
> 
> 22.11.2013 19:18, Mons Anderson пишет:
> По моему еще тогда выяснили, что резолвинг звался до форка.
> А это известная проблема AE::DNS
> 
> On 22.11.2013, at 19:17, Анатолий Гришаев <0body0 на rambler.ru> wrote:
> 
> А ты победил свою беду с AnyEvent::DNS или просто её неправильно готовил?
> Если да, то в чём собака порылась?
> 
> 22.11.2013 18:49, ksvs пишет:
> Это я так засомневался, когда к своей мултипроцесной асинхроной штуке, прикрутил нагрузку по анализу скачиваемых html, и увидел, что вариант с 2 двумя рабочими дочерними процессами (у меня два ядра) и с 100 асинхронных сокетов в каждом дает такую же производительность, как и вариант с 8 рабочими дочерними синхронными процессами. В общем, узкое место стало CPU.
> 
> 
> Анатолий.
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org

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