LINUX.ORG.RU

Асинхронные бенчмарки HTTP в PyPy3

 , , , ,


2

3

(мой перевод, оригинал - https://morepypy.blogspot.ru/2017/03/async-http-benchmarks-on-pypy3.html) Асинхронные бенчмарки HTTP в PyPy3

Всем привет, мы упорно трудились с того момента, как Mozilla сделала пожертвование проекту PyPy, для того, чтобы предоставить вам работающую реализацию Python 3.5

Мы почти готовы выпустить альфа версию PyPy3.5. Наша цель - выпустить релиз почти сразу после спринта (прим. - тут говорится о Leysin Sprint, который проводится разработчиками PyPy почти каждый год). Множество модулей было портировано, и PyPy3.5 уже может запускать множество Python 3 программ. Мы будем рады получить любые отзывы после предстоящего релиза.

Чтобы показать, что сердце (asyncio) Python 3 уже может работать, мы приготовили несколько бенчмарков. Они были сделаны Paweł Piotr Przeradowski, twitter @squeaky_pl . Их цель - проверить производительность HTTP с несколькими асинхронными IO библиотеками, а именно относительно новыми asycnio и curio, и протестированными в бою tornado, gevent, и Twisted. Исходный код доступен на https://github.com/squeaky-pl/zenchmarks, и инструкции о воспроизведении результатов могут быть найдены в README.md. «Сырые» результаты могут быть взяты из https://github.com/squeaky-pl/zenchmarks/blob/master/results.csv

Цель представленных бенчмарков - показать, что предстоящий релиз PyPy3 уже может работать с кодом, который работает на CPython 3.5, без изменений. PyPy3 так же способен улучшить скорость этого кода.

Бенчмарки состоят из HTTP серверов, реализованных на основе упомянутых библиотек. Все сервера однопоточны, и зависят от лежащих в основе циклов событий (event loop'ов) для обеспечения параллелизма (concurrency). Логгирование доступа было выключено, чтобы исключить производительность терминального I/O из результатов. Код вьюшек (прим. - view code - не смог нормально перевести) состоит из поиска в словаре, который соотносит ASCII буквы к строкам из популярного Zen of Python. Если строка найдена - вьюшка её возвращает, а иначе отдаётся ответ 404 Not Found. Ошибки 400 Bad Request и 500 Internal Server Error так же обрабатываются.

Нагрузка была сгенерирована с помощью утилиты для бенчмаркинга HTTP - wrk. Она была запущена в одном потоке, открывающем до 100 одновременных подключений на 2 секунды, и повторяла нагрузку 1010 раз для последовательных результатов (прим. - большей частью для разогрева PyPy). Так же использовался Lua скрипт, который инструктирует wrk постоянно посылать 24 разных запроса, которые достигают разные пути исполнения (execution paths) (200, 404, 400) в коде вьюшек. Стоит отметить, что wrk посчитал только 200 ответов, как успешные, т.е. фактическое кол-во запросов в секунду выше.

Для вашего удобства все использованные версии библиотек находятся в репозитории. Там так же имеется скомпилированная портативная версия wrk, которая должна работать на любом более-менее современном (как максимум - 10 лет) Linux x86_64 дистрибутиве. Бенчмарк был запущен на публичном облаке scaleway - x86_64 сервере, запущенном в парижском дата центре. Сервер использовал Ubuntu 16.04.01 LTS и сообщал о процессоре Intel(R) Xeon(R) CPU D-1531 @ 2.20GHz. CPython 3.5.2 (есть по умолчанию в Ubuntu) был протестирован против снапшота pypy-c-jit-90326-88ef793308eb-linux64 из ветки совместимости с Python 3.5.

Мы хотим поблагодарить Mozilla за поддержку нашего дела!

С уважением, fijal, squeaky_pl и команда PyPy

P.S: Графики есть в оригинальном посте и в репозитории.



Последнее исправление: Tiberium (всего исправлений: 1)

Какой, собственно говоря толк в асинхронных инструментах в пистоне, если большая часть инструментов, написанных на нем имеют синхронный интерфейс. Не использовать питоновский код? Заново изобретать nodejs?

actionpattern
()
Ответ на: комментарий от actionpattern

Т.е. вообще не делать ничего нового, основанного на асинхронности, и только пользоваться nodejs?

Tiberium
() автор топика
Ответ на: комментарий от anonymous

А это какое, вообще, имеет отношение к делу? Речь о том, что если использовать, к примеру, синхронные библиотеки в асинхронном коде, все плюшки асинхронности накроются медным тазом

actionpattern
()
Ответ на: комментарий от actionpattern

Речь о том, что если использовать, к примеру, синхронные библиотеки в асинхронном коде, все плюшки асинхронности накроются медным тазом

Речь о том, что если использовать c в пистоне или nodejs, то все плюшки автоматического управления памятью накроются медным тазом

А это какое, вообще, имеет отношение к делу?

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

anonymous
()
Ответ на: комментарий от anonymous

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

Имеет отношение. Смысла в асинхронности просто нет, в этом случае. Все равно внутри будет блокирующий код

actionpattern
()
Ответ на: комментарий от actionpattern

Значит, не пиши. Тот, кому нужно, возьмет асинхронный драйвер к бд, хранилищу, и всему, чему нужно.

anonymous
()
Ответ на: комментарий от actionpattern

Смысла в асинхронности просто нет, в этом случае. Все равно внутри будет блокирующий код

Ну так не делай так. Хочешь - пиши синхронный код. Хочешь - перепиши всё асинхронно. Знаешь язык, на котором ты напишешь всё быстрее - пиши на нём.

Что тебя беспокоит-то?

anonymous
()
Ответ на: комментарий от anonymous

так в том же nodejs почти вся инфраструктура завязана на асинхронщине. Это все создавалось несколько лет к ряду, все уже готово. Зачем велосипеды городить?

actionpattern
()
Ответ на: комментарий от actionpattern

так в том же nodejs почти вся инфраструктура завязана на асинхронщине. Это все создавалось несколько лет к ряду, все уже готово. Зачем велосипеды городить?

На земле миллиарды людей который несколько лет кряду росли, учились и давно уже работают. Зачем ты родился?

anonymous
()
Ответ на: комментарий от actionpattern

так в том же nodejs почти вся инфраструктура завязана на асинхронщине

И что теперь? Вместо бла-бла напиши, какую проблему с асинхронным стилем не решить на питоне с его инфраструктурой.

anon1984
()
Ответ на: комментарий от actionpattern

Где есть готовые решения? Это на том браузероязычке, который упоротые звери из браузера вынули?

anonymous
()
Ответ на: комментарий от actionpattern

Schuldiner–Пруфов не будет.ogg

Ясно. Наредкость глубокая аналитика.

anon1984
()
Ответ на: комментарий от actionpattern

js это не решение, а недоразумение, вместе с вашей нодой.

alienclaster ★★★
()
18 августа 2017 г.
Ответ на: комментарий от genryRar

Разбор, отчего мы не любим asyncio-мразоту

asyncio - вообще какаха едва ли не страшнее твистеда. У меня кот иногда отрыгивает такие шарики из свалявшихся волос, обмазанные остатками полупереваренной пищи. Вот asyncio - оно такое. Там пятнадцать слоёв абстрации, перепутанных друг с другом, всё обмазано обратной совместимостью со старыми корутинами на йилдах. Стопицот однотипных сущностей: таски, фьючеры, корутины... Ортогональность и компактность - че? Кондовые протоколы на калбеках, причём эти калбеки могут быть только синхронными! Хочешь вызывать асинхронный код в методе .data_received()? Авотхуй! Юзай add_done_callback(). Зачем нам корутины, если можно херачить лапшу на калбеках? Заглянешь в сорцы - кругом мегатонны говномагии, неявная буферизация. Вот хороший разбор: https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-as... - на asyncio просто невозможно писать корректный сетевой код! Потому что внутри у ей ГОВНО. Нужно прикладывать особые усилия, чтобы в него не вляпаться, но оно везде. Кстати, в статье разбирается curio, но к gevent-у всё сказанное тоже относится. Ни у него, ни у curio нет тех проблем, что есть у asyncio. Не используйте asyncio, обходите это говно стороной. Если незнакомые люди будут предлагать вам писать на asyncio - гоните их, насмехайтесь на ними, по-всякому показывайте им, что они - изгои. И юзайте gevent. Юзайте gevent. Юзайте блджад gevent. А если религия не позволяет писать простой код без мусора async и await - юзайте curio. Для общего развития советую также изучить устройство https://trio.readthedocs.io/ как пример хорошего дизайна в вакууме. А в жизни просто юзайте curio или gevent. Peace!

anonymous
()
Ответ на: Разбор, отчего мы не любим asyncio-мразоту от anonymous

в реальном проекте так и не довелось асинкио использовать, но палочкой тыкал в свободное время. во внутренности не заглядывал, но по первому впечатлению ничего прям криминального не заметил.
мне показалось, у нее есть один серьезный плюс перед geventом - она явно не дает тебе прострелить ногу, вызвав евентлуп-блокирующий код в колбеке. или я неправ? когда палочкой его тыкал, он мне толи варнинг кидал толи ошибку выдавал, непомню. хотя если путаю и этого нет, то тогда и профита от нее явного нет.

люблю gevent, но вот случайно отстреленная нога... ведь вроде ничего беды не предвещает, а потом так забудешь проверить и дернешь из коротины какуюнибуть хрень. ведь помнишь, что эта хрень сторонняя и потоки при вызове не блочит. но окажется что под gevent она неадаптирована и там ведет себя иначе. и натебе, блокировка... хотя может я слона раздуваю, сам попался на это всего дважды. просто запомнилось сколько сил ушло на поиск, откуда блокировка появилась.

ах да, и еще gevent может себя непредсказуемо вести при переключении с него на нативные потоки в рантайме. понятно, что это крайне ненормальный сценарий и лучше так вообще не делать. но если очень нужно, то тут возникают крайне тяжело отлавливаемые баги^^

genryRar ★★
()

Ничеси проблемы в питухоне.

ritsufag ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.