Здравствуйте, Ночной Смотрящий, Вы писали:

V>>Там где пашет десяток явовских серверов приложений, там справляется одна железка на С++.
НС>Много железок делают не только для перфоманса, но и для таких вещей как надежность

Слишком очевидное замечание...

Вопрос надёжности при линейном масштабировании разбиваются на два: надёжность исполнителей и надёжность диспетчера, который распределяет задачи по исполнителям.
В случае С++ этот вопрос сводится ко второму, сценарий обыгрывания сбоев которого проще — просто запускается резервный "диспетчер", он же исполнитель в случае С++.
Для джавовских серверов такой диспетчер обычно нейтивный и в этом тоже есть свой резон — время его запуска составляет менее секунды, тогда как время запуска сервера приложений может составлять несколько секунд или десятки секунд с учётом "разогрева", т.е. выхода на адекватный перформанс.


НС>или геораспределенность.

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


НС>Чуть менее чем у всех облачных проектов, которыми я занимался последние три года те машины, где идет активная работа с БД — это, как правило, 2-4 1-2 ядерных машины со средней загрузкой CPU 10-20%.

БД тоже разные бывают.
У бирж специализированные БД с временем отклика в микросекунды и чудовищной пропускной способностью.


НС>На фоне кластеров в десятки многоядерных машин, которые как раз CPU bound и к БД почти не обращаются. И там, конечно, перформанс меппера из БД ну очень важен.

Э-э-э, показанный код имеет дело по-сути не с БД, а с протоколом общения с ней.
Т.е. показанный принцип применим для работы с любым бинарным протоколом.

Из живой практики пример (многолетней давности, но всё же).
Относительно "в лоб" был написан обработчик трафика от одной из бирж, на тестовых соединениях работал прекрасно, при живом коннекте в "часы пик" переполнялась очередь, обрабатывающая входные пакеты протокола. "Творчески подойдя", уменьшил тикозатраты примерно в 20 раз, что позволило одной железке обрабатывать больше фидов одновременно (на 10+ гигабитных карточках можно кушать данные не ложками, а половниками, как грится).

Я так думаю, что все понимают, что презентация была не о доступе к БД, а о возможностях писать эффективный код относительно выразительными новыми ср-вами последних версий С++ (относительно выразительности диалекта С++03).

У меня есть кое-какие эксперименты и насчёт .Net Core в этом плане, могу поделиться.
Заодно, если уж ты общался (и еще будешь общаться) с ведущими разработчиками — там есть на что указать, на небольшие косяки, исправление которых улучшит те самые битовыжимательные сценарии.