Микросервисами

это как?

а как django/flask скрестить с asyncio? :)

Сложнее уже, думаю. Asyncio не очень хорошо совмещается с WSGI.

Микросервисами

Ну только если так, да

это как?

Писать на чем нужно требуемый функционал, связывая апишками

Писать на чем нужно требуемый функционал, связывая апишками

эммм... и как быть если тебе нужно ходить в бд и нужны модели django/sqlalchemy?

Всё через API, вообще всё.

Лучше через апи, да, чем как-то извращаться франкенштейном

Всё через API, вообще всё.

огонь. дёрнуть метод у модельки - api. вообще любой чих - апи.

да!

Exactly. Но так как всё на локалке, оверхед хоть и получается, но небольшой

огонь. дёрнуть метод у модельки - api. вообще любой чих - апи.

Если у тебя прямо совсем связность, пиши на одном фреймворке

Чем выдумывать проблему :)

На самом деле можно же делать монолит + несколько микросервисов для специфичных задач

Exactly. Но так как всё на локалке, оверхед хоть и получается, но небольшой

да ну? чего одна сериализация и диспетчеризация будет жрать

да ну? чего одна сериализация и диспетчеризация будет жрать

Вот прям уж так много будет жрать.

Exactly. Но так как всё на локалке, оверхед хоть и получается, но небольшой

докер же есть... и сразу пишется так, как оно будет на проде вертеться, без лишних телодвижений "хмммм, а как теперь вот это вот перенести"

Опять-таки, микросервисы — не панацея.

энивей... @nazarov_tech а доклады на декабрь еще не забиты?

Опять-таки, микросервисы — не панацея.

меньшее из зол хД

Вот прям уж так много будет жрать.

а что у нас есть из быстрых фреймворков api?

https://klen.github.io/py-frameworks-bench/

легендарная ссылка

Asyncio-фреймворки проседают на первом тесте почему-то

Asyncio-фреймворки проседают на первом тесте почему-то

ожидаемо вполне

https://klen.github.io/py-frameworks-bench/

автор не умеет тестить и не понимает что делает. однако, первый тест адекватен и близок к реальности

а как надо? @pragus

а как надо? @pragus

используя голову ) вот $ wrk -d20s -t10 -c200 [URL] wtf? -t10 создает 10 тредов, при том что у него MacBook Pro 2015, CPU: 2.7GHz i5, где I5-5257U в котором 2 ядра и HT(итого 4 логических).

а как проводить тестирование у себя на локалке, если ресурсов немного?

энивей... @nazarov_tech а доклады на декабрь еще не забиты?

слоты есть)

а как проводить тестирование у себя на локалке, если ресурсов немного?

Лучше наверное сервак снять на пару часов, благо недорого совсем

и что там запускать?

и да деплой чего-то неочевидно долгий, но фиг с ним допустим задеплоили

а как проводить тестирование у себя на локалке, если ресурсов немного?

как минимум понимая соотношение между мишенью и генератором нагрузки.

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

да

ну это же вообще жопа

Asyncio-фреймворки проседают на первом тесте почему-то

там не очень честное сравнение, потому что тот же meinheld - один из самых быстрых event loop и задача первого теста - это про "быстро принять коннект и выплюнуть json". json у всех +/- одинаковый и дальше остается только оверхед от event loop. фактически, там сравнивается event loop + http-сервер.

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

там еще зачем-то лишние треды и они у него дралось за ресурсы.

falcon-bench, pypy2 Results: 1. falcon..............367889 req/sec or 2.72 μs/req (172x) 2. bottle..............197207 req/sec or 5.07 μs/req (92x) 3. falcon-ext..........181582 req/sec or 5.51 μs/req (85x) 4. werkzeug.............65341 req/sec or 15.30 μs/req (31x) 5. django...............15540 req/sec or 64.35 μs/req (7x) 6. flask.................3041 req/sec or 328.84 μs/req (1x) 7. pecan.................2136 req/sec or 468.09 μs/req (1x)

falcon-bench, pypy3 Results: 1. falcon..............111719 req/sec or 8.95 μs/req (192x) 2. bottle...............99140 req/sec or 10.09 μs/req (171x) 3. falcon-ext...........22898 req/sec or 43.67 μs/req (39x) 4. werkzeug.............18269 req/sec or 54.74 μs/req (31x) 5. flask................15227 req/sec or 65.67 μs/req (26x) 6. django...............15005 req/sec or 66.64 μs/req (26x) 7. pecan..................581 req/sec or 1722.19 μs/req (1x)

Ну flask очень условно, большинство проектов все равно на django.

Если убрать фантики, то фласка много.

тут все просто - джангу делали в США и ее любят в новом свете, а фласк делали в Австрии и ее любят в старом свете)

Австрия не Австралия

Ох, вот эти все микрооптимизации это прям бич разработки. конечно прикольно мериться циферками, чувствуешь себя ИНЖЕНЕРОМ, делаешь чтобы СКЕЙЛИЛОСЬ. Вот только в итоге сроки съехали, написано куча лишнего кода (который бы не пришлось бы писать с более большими и взрослыми инструментами), а пользователей все нет, так что не понятно куда и зачем скейлить. А потом раз и пивот и все нужно выкидывать ?

кек, подсказка: есть не стартапы

кек, подсказка: есть не стартапы

Не ну если уже есть продукт, определен боттлнек и надо оптимизировать то кто же спорит. Есть пользователи - значит заслужил пооптимизировать и поиграть в архитектора ?

имхо, это про "одинаково плохо уметь обе вещи"

Современный фронт, при наличие людей, которые за тобой нахачат под старые браузеры, весьма programmer friendly

Ох, вот эти все микрооптимизации это прям бич разработки. конечно прикольно мериться циферками, чувствуешь себя ИНЖЕНЕРОМ, делаешь чтобы СКЕЙЛИЛОСЬ. Вот только в итоге сроки съехали, написано куча лишнего кода (который бы не пришлось бы писать с более большими и взрослыми инструментами), а пользователей все нет, так что не понятно куда и зачем скейлить. А потом раз и пивот и все нужно выкидывать ?

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

:) Сентри он не сделал :) Он участвовал, присоединившись после создания, если не ошибаюсь

Ага, и пишет там на расте в итоге.

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

Ну python заведомо медленный, как и ruby ? но если вилосипеды не изобретать и не использовать маргинальные полузаброшенные библиотеки то скорость разработки высокая, а performance более-менее норм. У меня просто бомбит со всех этих синтетических тестов который только json выдают и таких же синтетических микро-фрэймворков заточенных под одну нужду.

Ну python заведомо медленный, как и ruby ? но если вилосипеды не изобретать и не использовать маргинальные полузаброшенные библиотеки то скорость разработки высокая, а performance более-менее норм. У меня просто бомбит со всех этих синтетических тестов который только json выдают и таких же синтетических микро-фрэймворков заточенных под одну нужду.

ну это... pypy же. да, медленный, но это не повод быть еще медленнее

Ага, и пишет там на расте в итоге.

Да :) Причем с год назад он на мой суппорт тикет отвечал по жсу :) Человек и пароход

ну это... pypy же. да, медленный, но это не повод быть еще медленнее

ну раз мы говорим о web то что по твоему медленно? стал бы ты например жертвовать экосистемой django или даже flask (которая в общем дохлая) и использовать, нпример sanic?

(за исключением случаев где надо просто наколбасить api proxy)

ну раз мы говорим о web то что по твоему медленно? стал бы ты например жертвовать экосистемой django или даже flask (которая в общем дохлая) и использовать, нпример sanic?

а что есть веб? современный веб - это spa, js и бэкенд который общается с этой приложенькой. при этом, spa - один из видов клиента, т.к. есть еще мобилки

а что есть веб? современный веб - это spa, js и бэкенд который общается с этой приложенькой. при этом, spa - один из видов клиента, т.к. есть еще мобилки

ну давай ограничемся чисто бэкэндом, обычный rest, который и SPA и мобилки юзают

ну давай ограничемся чисто бэкэндом, обычный rest, который и SPA и мобилки юзают

угу. и?

угу. и?

ну ты сказал "заедомо медленный". является например django заведомо медленным и стал бы ты менять все ти ништяки которые он дает на условный sanic который заведомо "побыстрее"?

ну ты сказал "заедомо медленный". является например django заведомо медленным и стал бы ты менять все ти ништяки которые он дает на условный sanic который заведомо "побыстрее"?

я бы не использовал django от слова совсем. взял бы apistar или hug.

ну ты сказал "заедомо медленный". является например django заведомо медленным и стал бы ты менять все ти ништяки которые он дает на условный sanic который заведомо "побыстрее"?

вот надо тебе сделать апишную часть сервиса, в который будут ходить 10-20млн юзеров. что ты возьмешь?

я бы не использовал django от слова совсем. взял бы apistar или hug.

apistart же совсем сырой, hug не знаю, не юзал

вот надо тебе сделать апишную часть сервиса, в который будут ходить 10-20млн юзеров. что ты возьмешь?

ну если мне надо crud то возьму django, запихаю все тяжелое в celery и успокоюсь. если перестанет вывозить то уже буду что-то оптимизировать по факту

алсо, то что требует поддержки соединений сразу буду писать на ноде, наигрался я с asyncio в python, спасибо

ну если мне надо crud то возьму django, запихаю все тяжелое в celery и успокоюсь. если перестанет вывозить то уже буду что-то оптимизировать по факту

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

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

тяжелое я имел в виду все то, что воркер блокирует, типа там запросы к внешним сервисам, какой-то процессинг, вот это вот все

ну именно потому, что задача простая (тое обычный crud) то возьму то, что делает это с минимальным бойлерплэйтом

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

ERROR: S client not available

Иногда просто не нужно заниматься преждевременной оптимизацией.

ну именно потому, что задача простая (тое обычный crud) то возьму то, что делает это с минимальным бойлерплэйтом

так у тебя большую часть времени будет занимать хождение в бд. для 15 млн юзеров даже равномерно размазанное по суткам хождение 1 раз в час в бд - это 10krps.

Иногда просто не нужно заниматься преждевременной оптимизацией.

это да ) надо просто сразу выбрать правильный инструмент )

Не правильный, а удобный, я бы сказал :)

Заказчику зачастую нужно быстро и чтобы работало

угу )

Если тебе удобно ложкой забивать гвозди, бери ложку

Именно

Иногда это быстрее, чем читать инструкции к молотку :D

Кто на что горазд :)

так у тебя большую часть времени будет занимать хождение в бд. для 15 млн юзеров даже равномерно размазанное по суткам хождение 1 раз в час в бд - это 10krps.

хуякс-хуякс и gevent ? работать через асинхронные биндинги с базой ваще не прикольно

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

и там апишечкая простая: узнать баланс, узнать остаток трафика, итп. и вот это все будет дергаться каждым раз в несколько минут

Если тебе удобно ложкой забивать гвозди, бери ложку

ну так смотря что тут ложка )

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

i'm gonna stop you right there. до 10 миллионов пользователей нужно идти не один год, это очень серьезная цифра. к тому времени как будет такая пользователькая база, куча всего поменяется, перепишется и будет уже понятно что оптимизировать. это именно то про что я говорю - даже бл%*$ не думайте про миллионы пользователей в самом начале

просто от души брат

i'm gonna stop you right there. до 10 миллионов пользователей нужно идти не один год, это очень серьезная цифра. к тому времени как будет такая пользователькая база, куча всего поменяется, перепишется и будет уже понятно что оптимизировать. это именно то про что я говорю - даже бл%*$ не думайте про миллионы пользователей в самом начале

а что идти? ) что если они у тебя уже есть? )

и это просто еще один сервис компании

а что идти? ) что если они у тебя уже есть? )

ну так я же вверху уже писал, что если есть продукт, пользователи и конкретные боттлнеки то это другой вопрос - конечно оптимизируйте, хоть там на go хоть на ноду переписывайте )

ну так я же вверху уже писал, что если есть продукт, пользователи и конкретные боттлнеки то это другой вопрос - конечно оптимизируйте, хоть там на go хоть на ноду переписывайте )

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

i'm gonna stop you right there. до 10 миллионов пользователей нужно идти не один год, это очень серьезная цифра. к тому времени как будет такая пользователькая база, куча всего поменяется, перепишется и будет уже понятно что оптимизировать. это именно то про что я говорю - даже бл%*$ не думайте про миллионы пользователей в самом начале

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

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

аа, но пользователи уже гарантированы? типа просто перекинутся на твой сервис? ну это да, уже нужно от цифр исходить

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

поэтому 12factor apps ? такая архитектура позволяет до поры до времени закидывать деньгами боттлнэки ?

аа, но пользователи уже гарантированы? типа просто перекинутся на твой сервис? ну это да, уже нужно от цифр исходить

об этом и речь. и я снова повторюсь: ты сидишь перед чистым листом и надо выбирать

об этом и речь. и я снова повторюсь: ты сидишь перед чистым листом и надо выбирать

ну если чисто вопрос в io то наверное бы и не стал python брать, написал бы на ноде. если надо с базой работать то другой вопрос, если это sql то возможно работу с базой вынес в другой сервис, на той же джанге например, а перед ней поставил сервис на ноде

ну если чисто вопрос в io то наверное бы и не стал python брать, написал бы на ноде. если надо с базой работать то другой вопрос, если это sql то возможно работу с базой вынес в другой сервис, на той же джанге например, а перед ней поставил сервис на ноде

elixir/erlang

elixir/erlang

вопрос вкуса )

поэтому 12factor apps ? такая архитектура позволяет до поры до времени закидывать деньгами боттлнэки ?

это вообще какое-то капитанство(я про twelve factor app)

это вообще какое-то капитанство(я про twelve factor app)

ну это сейчас кажется как капитанство, а тема то старая

имхо, это про "одинаково плохо уметь обе вещи"

большинству проектов этого, видимо, хватает

ну если чисто вопрос в io то наверное бы и не стал python брать, написал бы на ноде. если надо с базой работать то другой вопрос, если это sql то возможно работу с базой вынес в другой сервис, на той же джанге например, а перед ней поставил сервис на ноде

да сколько ж говорить, что ipc/rpc сильно дорогое(причем как по ресурсам, так и по latency). дешевое - это shared memory, но его почти никто не использует(или же просто не умеет).

большинству проектов этого, видимо, хватает

?