<html><head><meta http-equiv="Content-Type" content="text/html charset=koi8-r"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 22.11.2013, at 21:24, Андрей П. Ковбович <<a href="mailto:akovbovich@gmail.com">akovbovich@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Тут прозвучал вопрос про некие узкоспециализированные решения, где асинхронная модель не подходит. Я так понимаю это случай, когда требуется строго последовательная обработка. Например, аукцион, когда нужно сматчить биды с асками в режиме fifo.<br></blockquote><div><br></div><div>Нет, я не такой случай имел в виду.</div><div>Алгоритмически асинхронное приложение не отличается от синхронного. т.е. там точно так-же можно выстроить строго последовательную обработку.</div><div><br></div><div>Пример, который я имел в виду:</div><div>Писал я UDP сервер. Мне нужно было проверить предельную нагрузку. Я сделал клиент, который заваливал интерфейс UDP пакетами.</div><div>Написал асинхронный udp сервер на perl/EV. мало пакетов при 100% CPU.</div><div>Написал аналогичный сервер на C/libev. Прирост 10-20%, 100% CPU.</div><div>Написал синхронный сервер на Pure Perl. Прирост 400%.</div><div><br></div><div>Ситуация оказалась довольно простая: в синхронном варианте всё, что делает сервер - это вызывает в цикле recv, тогда как в асинхронном почти на каждый пришедший пакет вызывается on_read watcher.</div><div><br></div><div>Решилось довольно просто.</div><div>SO_RECVBUF был поднят до нескольких мегабайт, а после прочтения пакетов из сокета следующий on_read ставился не сразу, а через 0.0001s.</div><div>После этого изменения на каждый on_read мы вычитывали не 1-2 пакета, а, в зависимости от значения таймера, от 10 до 1000 пакетов за 1 раз.</div><div><br></div><div>соответственно оверхед от ev был сведен к процентам и производительность получилось почти такая, как у синхронного варианта.</div><div><br></div><div>PS: Perl/EV на 1 core при 100% загрузке CPU в пределе может обработать около 450-500k udp pkt/s</div><br><blockquote type="cite">
<br>пятница, 22 ноября 2013 г. пользователь Анатолий Гришаев <<a href="mailto:0body0@rambler.ru">0body0@rambler.ru</a>> писал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Мне показалось, что нет.<br>
А до этого в переписке было аналогичное решение твоему решение.<br>
<br>
И ksvs не написал, чем закончилось, и может и твоё решение не подошло.<br>
Хотел знать из первых рук, чего было и чем закончилось.<br>
<br>
22.11.2013 19:18, Mons Anderson пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
По моему еще тогда выяснили, что резолвинг звался до форка.<br>
А это известная проблема AE::DNS<br>
<br>
On 22.11.2013, at 19:17, Анатолий Гришаев <<a>0body0@rambler.ru</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
А ты победил свою беду с AnyEvent::DNS или просто её неправильно готовил?<br>
Если да, то в чём собака порылась?<br>
<br>
22.11.2013 18:49, ksvs пишет:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Это я так засомневался, когда к своей мултипроцесной асинхроной штуке, прикрутил нагрузку по анализу скачиваемых html, и увидел, что вариант с 2 двумя рабочими дочерними процессами (у меня два ядра) и с 100 асинхронных сокетов в каждом дает такую же производительность, как и вариант с 8 рабочими дочерними синхронными процессами. В общем, узкое место стало CPU.<br>
<br>
<br>
</blockquote>
Анатолий.<br>
-- <br>
Moscow.pm mailing list<br>
<a>moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/" target="_blank">http://moscow.pm.org</a><br>
</blockquote></blockquote>
<br>
-- <br>
Moscow.pm mailing list<br>
<a>moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/" target="_blank">http://moscow.pm.org</a><br>
</blockquote>
-- <br>Moscow.pm mailing list<br><a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org">http://moscow.pm.org</a><br></blockquote></div><br></body></html>