Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Там где пашет десяток явовских серверов приложений, там справляется одна железка на С++. НС>Много железок делают не только для перфоманса, но и для таких вещей как надежность
Слишком очевидное замечание...
Вопрос надёжности при линейном масштабировании разбиваются на два: надёжность исполнителей и надёжность диспетчера, который распределяет задачи по исполнителям.
В случае С++ этот вопрос сводится ко второму, сценарий обыгрывания сбоев которого проще — просто запускается резервный "диспетчер", он же исполнитель в случае С++.
Для джавовских серверов такой диспетчер обычно нейтивный и в этом тоже есть свой резон — время его запуска составляет менее секунды, тогда как время запуска сервера приложений может составлять несколько секунд или десятки секунд с учётом "разогрева", т.е. выхода на адекватный перформанс.
НС>или геораспределенность.
При геораспределенности можно смело говорить о независимой работе серверов приложений, т.к. это резко отличается от стандартного джавовского сценария, когда на входе стоит один нейтивный диспетчер, затем стоит десяток-другой джавовских серверов приложений, которые все лезут опять в одну нейтивную базу. Как ни крути, но в этой консерватории что-то не то. ))
НС>Чуть менее чем у всех облачных проектов, которыми я занимался последние три года те машины, где идет активная работа с БД — это, как правило, 2-4 1-2 ядерных машины со средней загрузкой CPU 10-20%.
БД тоже разные бывают.
У бирж специализированные БД с временем отклика в микросекунды и чудовищной пропускной способностью.
НС>На фоне кластеров в десятки многоядерных машин, которые как раз CPU bound и к БД почти не обращаются. И там, конечно, перформанс меппера из БД ну очень важен.
Э-э-э, показанный код имеет дело по-сути не с БД, а с протоколом общения с ней.
Т.е. показанный принцип применим для работы с любым бинарным протоколом.
Из живой практики пример (многолетней давности, но всё же).
Относительно "в лоб" был написан обработчик трафика от одной из бирж, на тестовых соединениях работал прекрасно, при живом коннекте в "часы пик" переполнялась очередь, обрабатывающая входные пакеты протокола. "Творчески подойдя", уменьшил тикозатраты примерно в 20 раз, что позволило одной железке обрабатывать больше фидов одновременно (на 10+ гигабитных карточках можно кушать данные не ложками, а половниками, как грится).
Я так думаю, что все понимают, что презентация была не о доступе к БД, а о возможностях писать эффективный код относительно выразительными новыми ср-вами последних версий С++ (относительно выразительности диалекта С++03).
У меня есть кое-какие эксперименты и насчёт .Net Core в этом плане, могу поделиться.
Заодно, если уж ты общался (и еще будешь общаться) с ведущими разработчиками — там есть на что указать, на небольшие косяки, исправление которых улучшит те самые битовыжимательные сценарии.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, lpd, Вы писали:
_>А вот у Яндекса ситуация с нагрузкой совсем другая и им очевидно очень полезно оптимизировать свой серверный софт, что они и делают (ведя разработку на современном C++).
А насколько по-твоему ты сможешь оптимизировать бэкенд на современном C++ по сравнению с классическим? Я думаю не более чем 10-15% _результирующей_ скорости. Эти цифры ничего не решают: там, где хватает одного сервера будет один; а там где 120, их будет 100. Это игры оптимизировали, чтобы обогнать конкурентов в графике, и этим завоевать большую популярность. А для серверов нужно просто выбирать подходящие языки, и сохранять код простым. Ты же, выиграв шаблонами даже 20% скорости, усложнишь код, что приведет к багам и сложности добавления новых фич. Лично я вообще против лишней оптимизации кодом, если только после специальных замеров и определения узких мест.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, gardener, Вы писали:
Pzz>>Ну никто и не предполагает, что на этом ассемблере можно руками написать программу, которая без изменений будет работать на разных архитектурах. Речь идет о том, чтобы в кодогенераторе компилятора можно было общие вещи написать единообразно. G>А например разное количество регистров? Как это единообразно решить?
Хуже того, а если еще не все регистры взаимозаменяемы..
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Ну давай, расскажи во что же оно "упирается", если не в CPU. НС>В саму РСУБД, в память.
Я пока так и не понял, что значит "упирается в РСУБД". Кто-то тут начал говорить смешные вещи о большом времени обработки одного запроса к БД, но это очевидно не влияет ни на что, кроме размера пула ожидающих сопрограмм. Если же под "упирается", подразумевается, что БД неспособна выдержать поток запросов от клиента, то это очевидно аварийная ситуация, гарантированно приводящая к краху системы — смысл её рассматривать?
А про память вообще смешно в контексте C++ приложения. Кстати, по ссылке на другую статью об их системе, которую я тут сегодня кидал, можно в комментариях увидеть например размер стека (у них используются stackful) сопрограмм — это 250 КБ. Можешь оценить в сравнение с оперативной памятью современных серверов...
_>>способных обработать любое число запросов НС>Так не бывает. При активной работе с БД она всегда самое слабое звено. Если же число запросов настолько мало, что это не так, то на генерацию таких запросов хватит копеечного кластера из пары самых дохлых мащин.
Ну понятно, что "любое число" — это для простоты рассуждений. А на практике достаточно чтобы БД просто справлялась с максимальным числом запросов пользователей и всё.
Здравствуйте, smeeld, Вы писали:
_>>Ууу какой запущенный случай. Т.е. вот ты реально считаешь, что если БД долго обрабатывает каждый запрос (но при этом может обрабатывать тысячи таких запросов одновременно), то сервер, работающий с ней, всегда будет большую часть времени "спать"? ))) S>Если все запросы поступят одновременно, то промежуточный сервак зависнет на время отклика БД. Если запросы будут "размазаны" во времени, то спать промежуточный сервак не будет, одни запросы будут приниматься, другие ждать ответа, третьи отдаваться etc. Основной посыл у меня в том, что те миллисекунды, за которые промежуточный сервак исполнит свою часть работы быстрее, чем если софт на нём будет на какой-нибудь Java (что на порядки чаще в тырпрайзах встерчается чем на C++, С++ там вообще редкость, на которую пальцем показывают), то это никак на общую картину работы всей системы клиенты<->микросервисы<->базы не повлияет.
Для клиента безусловно никакой разницы не будет. Тут ты абсолютно прав. А вот для владельца системы будет вполне себе существенная разница в оплате разного количества требуемых для микросервисов железяк.
Здравствуйте, lpd, Вы писали:
_>>А вот у Яндекса ситуация с нагрузкой совсем другая и им очевидно очень полезно оптимизировать свой серверный софт, что они и делают (ведя разработку на современном C++). lpd>А насколько по-твоему ты сможешь оптимизировать бэкенд на современном C++ по сравнению с классическим? Я думаю не более чем 10-15% _результирующей_ скорости. Эти цифры ничего не решают: там, где хватает одного сервера будет один; а там где 120, их будет 100.
Ну а если там где было 12000, а после оптимизации станет 10000? Как думаешь, разница в их оплате окупит зарплату нескольких высококлассных программистов на C++?
lpd>Это игры оптимизировали, чтобы обогнать конкурентов в графике, и этим завоевать большую популярность. А для серверов нужно просто выбирать подходящие языки, и сохранять код простым. Ты же, выиграв шаблонами даже 20% скорости, усложнишь код, что приведет к багам и сложности добавления новых фич. Лично я вообще против лишней оптимизации кодом, если только после специальных замеров и определения узких мест.
Вообще говоря использование их драйвера и вообще всего фреймворка (https://habr.com/ru/company/yandex/blog/474438/) максимально простое для его пользователей (рядовых программистов Яндекса). Вот внутри там действительно относительно (попроще Boost'а) нетривиальная шаблонная магия. Однако чтобы пользоваться библиотечкой, разбираться в этой магии не требуется — внешний интерфейс там не сложнее чем у какого-нибудь std::vector.
Здравствуйте, alex_public, Вы писали:
_>Ну а если там где было 12000, а после оптимизации станет 10000? Как думаешь, разница в их оплате окупит зарплату нескольких высококлассных программистов на C++?
Я к тому, что у бизнеса серверов и у создателей тех же игр разные зависимости прибыль/(затраты на ИТ). Ускорение движка игры на 20% и улучшение графики по сравнению с конкурентами за счет этого прямо и сильно влияет на популярность, причем железо покупают геймеры. Ну и в играх обычно разве что баги фиксят после выпуска. А у гугла и яндекса прибыли несоразмерны затратам на ИТ(и на программистов и на сервера), поэтому они могут купить больше железа, и им важнее стабильность и поддерживаемость кода. Как гугл и яндекс рассуждают на самом деле я не знаю, но вот для Андроида гугл выбрал вообще Java, в том числе для GUI, так что я бы не считал эти две компании авторитетами.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, alex_public, Вы писали:
_>Если же под "упирается", подразумевается, что БД неспособна выдержать поток запросов от клиента, то это очевидно аварийная ситуация, гарантированно приводящая к краху системы — смысл её рассматривать?
Что за детский сад? Производительность БД не триггер, работает/не работает. Она падает по какой то зависимости от нагрузки. И чтобы очень мощный сервер БД нагрузить очень сильно, достаточно очень слабой машины клиента. В итоге БД может стоить несколько тысяч баксов в месяц, а машины фронта — сотню за пару, и при этом CPU у них будет в среднем процентов на 10 загружен. Как думаешь, имеет смысл в такой системе оптимизация меппинга данных на клиенте, или стоит заняться оптимизацией запросов?
_>А про память вообще смешно в контексте C++ приложения. Кстати, по ссылке на другую статью об их системе, которую я тут сегодня кидал, можно в комментариях увидеть например размер стека (у них используются stackful) сопрограмм — это 250 КБ.
При чем тут стек? Выборки из БД занимают место в памяти, и оно не особо зависит от того, С++ там или нет.
_>Ну понятно, что "любое число" — это для простоты рассуждений. А на практике достаточно чтобы БД просто справлялась с максимальным числом запросов пользователей и всё.
На практике такая БД будет на порядок-другой дороже фронта, рассчитанного на такую же нагрузку.
Здравствуйте, vdimas, Вы писали:
V>>>Там где пашет десяток явовских серверов приложений, там справляется одна железка на С++. НС>>Много железок делают не только для перфоманса, но и для таких вещей как надежность V>Слишком очевидное замечание...
V>В случае С++ этот вопрос сводится ко второму, сценарий обыгрывания сбоев которого проще — просто запускается резервный "диспетчер", он же исполнитель в случае С++.
Какой, нафик, диспетчер, о чем ты? Load Balancer что ли?
V>Для джавовских серверов такой диспетчер обычно нейтивный
В облаке он часто вообще железый. Но проблема вообще не в нем, а в самих серверах, выполняющих прикладную логику. Если у тебя такой сервер один, на чем бы он не был писан — с SLA у тебя будут проблемы.
V> и в этом тоже есть свой резон — время его запуска составляет менее секунды, тогда как время запуска сервера приложений может составлять несколько секунд или десятки секунд
В реальности от единиц до десятков минут.
НС>>или геораспределенность. V>При геораспределенности можно смело говорить о независимой работе серверов приложений
Нельзя.
V>, т.к. это резко отличается от стандартного джавовского сценария,
Нет никакого стандартного джавовского сценария в природе.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Для джавовских серверов такой диспетчер обычно нейтивный НС>В облаке он часто вообще железый.
Или на nginx и его аналогах.
"Железный" диспетчер — это тоже тупо линуховый или freebsd бокс с прошивкой.
НС>Но проблема вообще не в нем, а в самих серверах, выполняющих прикладную логику.
Верно, но возражая таким образом, ты делаешь вид, что не понимаешь, о чём тебе говорят. ))
Да, проблема в потенциальном падении проги сервера, однако джавовские серваки обычно не обеспечивают живое дублирование сессии на другом узле.
Т.е. получается или потеря сессии для stateful или подсовывание другого сервака для stateless.
Аналогично происходит с перезапуском нейтивного сервера — с теми же эффектами и примерно теми же таймингами.
НС>Если у тебя такой сервер один, на чем бы он не был писан — с SLA у тебя будут проблемы.
Если б ты еще сценарии внимательно в голове протрассировал, понял бы, как это работает.
V>> и в этом тоже есть свой резон — время его запуска составляет менее секунды, тогда как время запуска сервера приложений может составлять несколько секунд или десятки секунд НС>В реальности от единиц до десятков минут.
Тем более.
А на что тратится это время, почему бы вслух не озвучить? ))
НС>>>или геораспределенность. V>>При геораспределенности можно смело говорить о независимой работе серверов приложений НС>Нельзя.
Можно, бо если используется еще +1 диспетчер на входе (типа как google.com перекидывает на google.ru), то такой +1 диспетчер будет и для нейтивной реализации, а за этим доп. диспетчером работают относительно независимые части системы.
V>>, т.к. это резко отличается от стандартного джавовского сценария, НС>Нет никакого стандартного джавовского сценария в природе.
Описанный сценарий более-менее устоявшийся при масштабировании джавовских серверов.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>В случае С++ этот вопрос сводится ко второму, сценарий обыгрывания сбоев которого проще — просто запускается резервный "диспетчер", он же исполнитель в случае С++. НС>Какой, нафик, диспетчер, о чем ты? Load Balancer что ли?
(некоторое время думал, отвечать ли на подобное нубство, бо уже за гранью, да еще в форме претензии...)
В общем, даже в доках MS речь идет о "диспетчере трафика Azure" или, например, узел, выполняющий "корневую" роль NLB в кластере так и называют — диспетчером.
Здравствуйте, alex_public, Вы писали:
_>>>Ну давай, расскажи во что же оно "упирается", если не в CPU. НС>>В саму РСУБД, в память. _>Я пока так и не понял, что значит "упирается в РСУБД".
Да брешут как дышат. ))
Это ж не в первый раз на эту тему беседа, минимум дважды обсуждали это даже слишком глубоко.
Когда припираешь их к стенке, то сразу начинают петь о каких-то супер-тяжелых запросах.
А на деле 99.9% фактического трафика к базе — это легкие запросы, которые разогретая база отдаёт за единицы ms или сотни микросекунд.
При большом трафике легких запросов — становится заметен классический эффект от pipeline с увеличением времени отклика, но аналогично происходит и на стороне сервера приложений, т.е. речь должна уже идти о кол-ве одновременно выполняемых операций и расходах в пересчёте на каждую из них.
Но в эту сторону обсуждение всё-равно никогда не пойдёт — проверено многократно.
Бегают как зайцы, петляют до последнего, потом сваливают.
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Если же под "упирается", подразумевается, что БД неспособна выдержать поток запросов от клиента, то это очевидно аварийная ситуация, гарантированно приводящая к краху системы — смысл её рассматривать? НС>Что за детский сад? Производительность БД не триггер, работает/не работает. Она падает по какой то зависимости от нагрузки. И чтобы очень мощный сервер БД нагрузить очень сильно, достаточно очень слабой машины клиента. В итоге БД может стоить несколько тысяч баксов в месяц, а машины фронта — сотню за пару, и при этом CPU у них будет в среднем процентов на 10 загружен. Как думаешь, имеет смысл в такой системе оптимизация меппинга данных на клиенте, или стоит заняться оптимизацией запросов?
Здравствуйте, lpd, Вы писали:
_>>А вот у Яндекса ситуация с нагрузкой совсем другая и им очевидно очень полезно оптимизировать свой серверный софт, что они и делают (ведя разработку на современном C++). lpd>А насколько по-твоему ты сможешь оптимизировать бэкенд на современном C++ по сравнению с классическим? Я думаю не более чем 10-15% _результирующей_ скорости.
На деле в 10-20 раз.
Вот такой фокус.
Т.е. на синтетических тестах джава или дотнета отстают от плюсов всего в 2-3 раза, а когда речь о большой реальной системе, т.е. о большой результирующей косвенности графа объектов и наслоений абстракций, то получи 10-20 раз.
lpd>Эти цифры ничего не решают
Твои не решают, а мои решают кардинально.
lpd>там, где хватает одного сервера будет один; а там где 120, их будет 100.
В реальных сценариях (не будем трогать уникальный яндекс или гугль) это работает чуть по другому — было 10-20 серверов, стал 1.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я написал о его сознательном выборе, отражающем его стиль мышления, и я не понимаю почему это вызывает у тебя такой баттхерт, что ты позволяешь себе прямо оскорблять собеседника.
Есть такой любопытный эффект — в наших больших городах люди какие-то невзрачные, землисто-серые лица, общий образ — как выцветшая фреска на стене.
Когда высмаркиваешь смог после всего лишь 4-х часов гуляния по городу, по-другому и быть не может.
Вот молодёжь и пытается внешне хоть как-то выделиться. ))
С образом мышления в техническом плане это может быть никак не связано, это социальный феномен.
Здравствуйте, lpd, Вы писали:
_>>Ну а если там где было 12000, а после оптимизации станет 10000? Как думаешь, разница в их оплате окупит зарплату нескольких высококлассных программистов на C++? lpd>Я к тому, что у бизнеса серверов и у создателей тех же игр разные зависимости прибыль/(затраты на ИТ). Ускорение движка игры на 20% и улучшение графики по сравнению с конкурентами за счет этого прямо и сильно влияет на популярность, причем железо покупают геймеры. Ну и в играх обычно разве что баги фиксят после выпуска. А у гугла и яндекса прибыли несоразмерны затратам на ИТ(и на программистов и на сервера), поэтому они могут купить больше железа, и им важнее стабильность и поддерживаемость кода.
Вообще то подобный код драйвера как раз повышает стабильность и поддерживаемость кода, который его использует. )
lpd>Как гугл и яндекс рассуждают на самом деле я не знаю, но вот для Андроида гугл выбрал вообще Java, в том числе для GUI, так что я бы не считал эти две компании авторитетами.
Андроид вообще то был изначально разработан неким стартапчиком, который Google просто купил. )
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Если же под "упирается", подразумевается, что БД неспособна выдержать поток запросов от клиента, то это очевидно аварийная ситуация, гарантированно приводящая к краху системы — смысл её рассматривать? НС>Что за детский сад? Производительность БД не триггер, работает/не работает. Она падает по какой то зависимости от нагрузки.
И? Это как-то влияет на нагрузку сервера приложений? ) А тогда зачем упоминать подобные лишнее сущности? )
НС>И чтобы очень мощный сервер БД нагрузить очень сильно, достаточно очень слабой машины клиента. В итоге БД может стоить несколько тысяч баксов в месяц, а машины фронта — сотню за пару, и при этом CPU у них будет в среднем процентов на 10 загружен. Как думаешь, имеет смысл в такой системе оптимизация меппинга данных на клиенте, или стоит заняться оптимизацией запросов?
Если у тебя вся нагрузка на приложения умещается в один сервер, то конечно же не стоит ничего оптимизировать. А вот если требуется много таких серверов, то смысл в оптимизации естественно будет.
_>>А про память вообще смешно в контексте C++ приложения. Кстати, по ссылке на другую статью об их системе, которую я тут сегодня кидал, можно в комментариях увидеть например размер стека (у них используются stackful) сопрограмм — это 250 КБ. НС>При чем тут стек? Выборки из БД занимают место в памяти, и оно не особо зависит от того, С++ там или нет.
Вообще говоря зависит, т.к. очень разные модели хранения объектов в C++ и скажем Java. Хотя может там кто-то и извращается (слышал про такое в попытках реализации реалтайм приложений на java) и передаёт данные не Java объектами, а битовыми массивами...
_>>Ну понятно, что "любое число" — это для простоты рассуждений. А на практике достаточно чтобы БД просто справлялась с максимальным числом запросов пользователей и всё. НС>На практике такая БД будет на порядок-другой дороже фронта, рассчитанного на такую же нагрузку.
И? Какая разница, что один компонент системы дороже дороже другого? Всё равно же необходимы оба...
Здравствуйте, alex_public, Вы писали:
_>И? Это как-то влияет на нагрузку сервера приложений? )
Влияет. Есть некий минимум, ниже которого мощность кластера быть не может. И этот минимум при соответствующей нагрузке вполне может быть избыточен.
Либо стоимость кластера, обращающегося к БД, может быть 1-2% от стоимости вычислительного кластера или БД, и на экономию затрат в размере 0.1% от общей суммы всем плевать.
_>Если у тебя вся нагрузка на приложения умещается в один сервер
Сама эта фраза говорит о том, что ты в облаках не особо в теме. Там почти никогда не бывает одного сервера, и дело вовсе не в нагрузке на CPU.
_>Вообще говоря зависит, т.к. очень разные модели хранения объектов в C++ и скажем Java.
Это все мелочи.
_>И? Какая разница, что один компонент системы дороже дороже другого?
Здравствуйте, vdimas, Вы писали:
V>Да, проблема в потенциальном падении проги сервера, однако джавовские серваки обычно не обеспечивают живое дублирование сессии на другом узле.
Чего это вдруг не обеспечивают? Я уж не говорю о том, что в большинстве случаев никакой сессии на серверах нет.
V>Т.е. получается или потеря сессии для stateful или подсовывание другого сервака для stateless.
Персистентные сессии лет 20 назад в джаве изобрели. Хотя это и bad design.
V>Аналогично происходит с перезапуском нейтивного сервера — с теми же эффектами и примерно теми же таймингами.
Ты, как и Алекс, вообще не понимаешь о чем говоришь. Ну какие, нафик, перезапуски, если там даже без перезапусков машин много? И очередной реквест может попасть на любую из них (sticky sessions это изврат, который даже не всеми LB поддерживается).
V>>> и в этом тоже есть свой резон — время его запуска составляет менее секунды, тогда как время запуска сервера приложений может составлять несколько секунд или десятки секунд НС>>В реальности от единиц до десятков минут. V>Тем более. V>А на что тратится это время, почему бы вслух не озвучить? ))
В основном на развертывание собственно ОС и прикладных решений, которые бывает гигабайтами весят. Забороть это можно либо очень сильно покоцанной ОС и прикладным кодом, либо serverless решениями типа ACI, но там свои тараканы, в частности сильно ограниченным размером пулов датацентра.
НС>>>>или геораспределенность. V>>>При геораспределенности можно смело говорить о независимой работе серверов приложений НС>>Нельзя. V>Можно, бо если используется еще +1 диспетчер на входе
Нельзя. И далеко не всегда там вообще LB на геолокацию есть, схемы бывают и посложнее.
V>(типа как google.com перекидывает на google.ru)
Это не для геораспределенности. Датацентров у гугла сильно меньше, чем локальных сайтов.
V>>>, т.к. это резко отличается от стандартного джавовского сценария, НС>>Нет никакого стандартного джавовского сценария в природе.
V>Описанный сценарий более-менее устоявшийся при масштабировании джавовских серверов.
Нет. Сейчас более менее устоявшийся это кубер+докер, и неважно на чем под реализован, на жабке или на С++.
