Комментарии 45
Крутая инфографика, приятно выглядит.
З.Ы. У вас опечатка в заголовке "Python vs пессимисты"
только вот питон и правда медленный как показывают бенчмарки...
https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=json&l=zijlz3-sf
Вы совершенно правы, именно поэтому, чтобы решить эту проблему, мы применили multiprocessing для горизонтального масштабирования
Но у вас же статья называется "Как выжать максимум из питона")
Выжимается из него далеко не максимум. Например, для десериализации жсона, можно выбрать https://github.com/ijl/orjson (который окажется под капотом вовсе не питоном, а растом). Ну и воркер, который переписывает из очереди в базу, кажется, что прилично будет занят I/O, поэтому можно еще попробовать asyncio (правда, асинхронный драйвер для монги на питоне не оч). Сниппет с кодом, при этом всем, увеличиться не то, чтобы очень сильно.
Ну и по-честному, мультипроцессингом вы максимум выжимаете не из питона, а из железа.
Вы правы, мы старались утилизировать железо по максимуму. И, на мой взгляд, тут важен именно кумулятивный эффект. А по поводу оптимизации самой сутевой части процессинга, то да - тут есть простор для улучшений. Кстати, Orjson - действительно классная библиотека. Мы ее активно применяли в ряде промышленных решений, т.к. обнаружили, как раз при профилировании, что стандартный json serializer не очень производителен... И даже контрибьютили ряд улучшений в части сериализации дат. Возможно, напишем об этом отдельную статью.
А запись в базу у вас как происходит, синхронно? Тогда всё понятно, ничего оно быстрее не станет работать.
Да, синхронно, и на первый взгляд может показаться, что производительность всей системы упирается исключительно в производительность СУБД. Но при этом, важно помнить, что MongoDb обеспечивает достаточно гибкие механизмы конкурентной обработки запросов - https://docs.mongodb.com/manual/faq/concurrency/#faq-concurrency
И чтобы задействовать эти механизмы, заложенные в самой БД, мы со стороны приложения должны обеспечить передачу запросов в базу максимально оперативно, в чем нам и помогает multiprocessing.
Помимо этого, повлиять на скорость записи, можно путем тюнинга write concern в СУБД - https://docs.mongodb.com/manual/core/replica-set-write-concern/
Спасибо за мнение! Отмечу, что multiprocessing - это, конечно, лишь один из инструментов для решения данной задачи. Существуют и другие варианты оптимизации и архитектурные подходы к решению.
Интересно, спасибо. Но ссылки бы облегчили чтение. Я про "институт IEEE опубликовал"
Только вот убер уже много лет как перешел на го и жаву. Но да, до этого был питон (а самый первый прототип вообще на пхп)
Ой, хайлоад и питон
Для начала мы вынуждены плодить уйму процессов из-за gil, общение между которыми, мягко говоря, не zero-cost, так что про параллельную обработку маленьких задач лучше забыть
Управление аллокациями - это тоже не про питон
Быстрый сетевой стек? Вроде на питоне в среднем rps раз в 100 меньше плюсовых/сишных альтернатив
Собственно сами вычисления - ну тут есть какие-то решения, которые позволяют либо jit получить, либо использовать сишную библиотеку
Так уж случилось, что в highload важен low-latency на ядро, иначе вы просто в железо упретесь. Питон в этом очень слаб, но он и не для этого
Конечно, python - это далеко не самый быстрый в плане производительности язык, но он позволяет ясно и прозрачно описывать достаточно сложную бизнес-логику, в том числе в контексте highload. Тем более, если требуемые показатели производительности достигаются (tps/rps), то почему бы и нет?
Конечно, накладные расходы (железо, которое, кстати, все время дешевеет) присутствуют при таком подходе к горизонтальному масштабированию, но это та цена, которую мы платим за скорость разработки, гибкость решения и простоту поддержки/сопровождения.
Языков в мире программирования масса, но корону по праву носит Python
Не слишком ли громко ?
Корону по определению носит тот язык на котором ты программируешь )
Ну а дальше холивары.
А о чём статья? О том что в стдлибе пайтона есть multiprocessing?
Напасть двадцать первого века - использовать языки сценариев для чего-то сложнее сценариев.
Да, универсальность python открывает все новые и новые горизонты его применения. Еще сравнительно недавно мы даже подумать не могли, что, например, в области анализа больших данных и машинного обучения python станет просто стандартом de facto. Это же здорово, что появляются новые способы применения привычных инструментов.
https://habr.com/ru/amp/post/519414/
А вы тут про хайлоад говорите - за планету страшно
В области анализа больших данных рулят Spark, H2O, всякие колоночные СУБД а-ля Clickhouse и прочие серьезные штуки. Python - лишь обёртка для обращения к ним. С тем же успехом можно писать про то что R рулит в анализе больших данных ибо имеет все те же самые инструменты взаимодействия с ними и заслуженно "примеряет корону в анализе".
А про печаль от питоновского пандас в анализе данных лучше всего написал сам создатель Pandas
Пайтон в определённом контексте, конечно, не плох. Но вот полное забивание на нормальную графику из стандартной библиотеки и мобилки вообще портят весь восторг. Круто было бы какое-нибудь Kivy затащить прям в основную ветку. В мобилках вообще половина штук ломается на этапе "а вот для этой архитектуры у нас нет сборок библиотек". После чего ребята из PySide говорят "мы не будем это тащить, потому что официально питон это не желает поддерживать мобильные платформы".
Языков в мире программирования масса, но корону по праву носит Python
Попахивает очередной идеей в статьей "Python лучший язык программирования", да он безусловно лучший, как и C++, C#, Java и др., если вы выбрали какой то язык для себя, но у каждого своя область применения.
У статьи не было цели показать, что какой то язык хуже, а какой то язык лучше. Тут каждый делает выбор сам. У всех разные предпочтения. Основная мысль статьи была в том, чтобы показать на примере, что можно расширить привычную область применения python и показать как решать задачи уровня highload. Безусловно, highload системы можно имплементировать на Java, C#, C и С++.
Мне кажется, что не совсем верно изложен подход. Python увеличивает скорость разработки, а недостатки связанные с его медлительностью в большинстве случаев можно нивелировать правильным выбором архитектуры. А теперь оцените сколько займет разработка аналогичного решения на "сишечке"? В настоящее время скорость выпуска релиза намного важнее требований к железу.
Вы абсолютно верно уловили одну из идей, изложенных в статье. У нас действительно сделано упор на грамотно построенную архитектуру, которая за счет возможностей горизонтального масштабирования нивелирует проблемы производительности по сравнению если бы данное решение запускалось на одном узле в олин поток в standalone режиме. Ну и скорость разработки, как вы верно подметили, сейчас один из решающих факторов.
А что Autodesk на питоне пишет? Если мне память не изменяет, то AutoCAD вообще был написан на Lisp. Maya? Нет, питон уже потом в неё встраивали. Max? Inventor? Fusion360? Generative Design? В самом деле, раскройте тему. Или речь идёт о каких-то скриптах, для автоматизации внутренней рутины?
Без него не было бы YouTube, Instagram и Uber: пошаговая инструкция о том, как выжать максимум из Python