Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Вот интересно, почему любители С++ так активно в топике хамят и переходят на личности? Как думаешь, это связано?
Вот тут
пользователь "Ночной Смотрящий" назвает "хипста-фриком" вполне конкретного человека, никаких аругментов привести не может, но виноваты у него при этом "любители С++", мололец, чо
Здравствуйте, alex_public, Вы писали:
_>Ха, интересно, если провести тестирование быстродействия работы с БД их "позорищем" и любым твоим (в смысле используемым тобой) инструментом, то во сколько раз это самое "позорище" окажется эффективнее? )))
Доклад не смотрел, но судя по описанию, главная плюшка там это простая конвертация данных БД в пользовательские структуры С++. Приятно, но к быстродействию в рантайме это особого отношения не имеет.
Здравствуйте, Skorodum, Вы писали:
S>Доклад не смотрел, но судя по описанию, главная плюшка там это простая конвертация данных БД в пользовательские структуры С++.
+ к этому еще и единообразная поддержка двух принципиально разных типов протоколов PostgreSQL: текстового и бинарного. И все это достигается как раз за счет шаблонов и возможностей C++17 (вроде if constexpr).
Здравствуйте, lpc, Вы писали:
KP>>А это не так уж и много имеет общего с "с сокетами, протоколами и потоками", да и тут активно внедряют Go. Хе-хе.
lpc>Дилетанта видно издалека. Никакого гоу и сплошные сокеты да протоколы (но потоков конечно мало, в основном спинят по одному на каждый cpu).
А зря. Go очень неплох на этом поприще. Особенно, если уметь его готовить.
Здравствуйте, alex_public, Вы писали:
_>Ещё раз: что значит упирается? Чем меньше тиков процессора тратится на обработку одного запроса, тем больше одновременных запросов может обработать один сервер, тем меньше серверов надо оплачивать — прямая бизнес-выгода.
Ну это при условии, что оно в CPU упрется. А не в диск, например, или в сеть.
Здравствуйте, smeeld, Вы писали:
S>>Проблема с этим утверждением в том, что уровень проектных решений будет ограничиваться, во-первых, имеющимся в вашем распоряжении инструментарием
S>Полный бред.
Аргументированно, да. Конечно же настоящий программист напишет программу на Фортране на любом языке программирования.
А вот если взять не smeeld настоящего программиста, а более-менее знающих C, C++, Java и Haskell-разработчиков и дать им одну и ту же более-менее сложную и объемную задачу, то неужели у них все решения вот прям 1-в-1 одинаковыми получатся? Как думаете?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>> Чем меньше тиков процессора тратится на обработку одного запроса, тем больше одновременных запросов может обработать один сервер, тем меньше серверов надо оплачивать — прямая бизнес-выгода. НС>В общем случае это неверно. Верно только для CPU bound задач, к которым активная работа с РСУБД точно не относится.
Ну давай, расскажи во что же оно "упирается", если не в CPU. Вот возьмём конкретный классический пример: есть приложение, которой получает http запросы (много много) от пользователей, трансформирует их в запросы к БД (расположенной естественно на нескольких других машинах и способных обработать любое число запросов в рамках задачи), ждёт результата из БД и возвращает его пользователю. Самая классика так сказать. Ну так и чем будет ограничено число одновременных запросов, которые сможет переварить такой сервер?
Здравствуйте, smeeld, Вы писали:
_>>Ха, интересно, если провести тестирование быстродействия работы с БД их "позорищем" и любым твоим (в смысле используемым тобой) инструментом, то во сколько раз это самое "позорище" окажется эффективнее? ))) S>Бро, сейчас данных столько, что любая БД, хоть аналитическая, хоть релляционная, на каком бы майнфрейме она не исполнялась, или на каком бы кластере он на исполнялась, отдаёт данные за время, по сравнению с которыми оптимизации производительности на уровне запрашивающего клиента-это абсолютно ненужная работа. Всё равно клиент успеет выспаться много раз, пока данные придут.
Я правильно понимаю, что ты считаешь, что количество одновременных запросов, обрабатываемых сервером, определяется полным (включая сон) временем обработки одного запроса?
Здравствуйте, alex_public, Вы писали:
_>Ну давай, расскажи во что же оно "упирается", если не в CPU. Вот возьмём конкретный классический пример: есть приложение, которой получает http запросы (много много) от пользователей, трансформирует их в запросы к БД (расположенной естественно на нескольких других машинах и способных обработать любое число запросов в рамках задачи), ждёт результата из БД и возвращает его пользователю. Самая классика так сказать. Ну так и чем будет ограничено число одновременных запросов, которые сможет переварить такой сервер?
Ну, например, пропускной способностью сетевой карты.
Здравствуйте, Skorodum, Вы писали:
_>>Ха, интересно, если провести тестирование быстродействия работы с БД их "позорищем" и любым твоим (в смысле используемым тобой) инструментом, то во сколько раз это самое "позорище" окажется эффективнее? ))) S>Доклад не смотрел, но судя по описанию, главная плюшка там это простая конвертация данных БД в пользовательские структуры С++. Приятно, но к быстродействию в рантайме это особого отношения не имеет.
Естественно доклад был совсем не про быстродействие. А вот весь проект целиком (кстати, как я понимаю, на него можно глянуть с чуть большей высоты например здесь https://habr.com/ru/company/yandex/blog/474438/) как раз про быстродействие...
Ну и если говорить конкретно про описываемый в докладе драйвер, то:
1. Там было упоминание о быстродействие как раз при объяснение зачем был написан свой драйвер (и да, быстродействие — это конечно же не единственный пункт, но один из) при сравнение бинарного и текстового протокола общения с СУБД (разница почти в сотню раз!).
2. В докладе явно отмечается активное использование сочетания if constexpr с шаблонами, что даёт оптимизации недоступные большинству других языков. Конечно это совсем мелкая экономия, но если она происходит например на каждом читаемом int'е...
3. Это всё же C++ и такой код будет априори быстрее из-за отсутствия накладных расходов.
Здравствуйте, alex_public, Вы писали:
_>Я правильно понимаю, что ты считаешь, что количество одновременных запросов, обрабатываемых сервером, определяется полным (включая сон) временем обработки одного запроса?
Нет количество одновременных запросов-это количество одновременных запросов. Время выполения каждого из них-это время выполнения каждого из них. И, если для каждого из них нужно лезь в базу и ждать оттуда данных, то общее время выполнения всех одновременных запросов будет равно максимальному времени выполнения одного запроса из всех одновременных. И, если БД тормозит, то сервак будет тормозить, он будет просто спать.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну это при условии, что оно в CPU упрется. А не в диск, например, или в сеть.
Все на одной машине, вся БД в памяти или рейд SSD, данные только читаются. Тут и миллионы запросов к БД в секунду можно обрабатывать
Здравствуйте, alex_public, Вы писали:
Pzz>>Ну, например, пропускной способностью сетевой карты.
_>Эм, ты давно видел скорости современных карт и скорости оперативной памяти? ))) Мы если что, не про твой старенький ноутбук, а про сервера... )
На 10+ гигабитах, говорят, операционная система с трудом успевает разгребать трафик.
Здравствуйте, smeeld, Вы писали:
_>>Я правильно понимаю, что ты считаешь, что количество одновременных запросов, обрабатываемых сервером, определяется полным (включая сон) временем обработки одного запроса? S>Нет количество одновременных запросов-это количество одновременных запросов. Время выполения каждого из них-это время выполнения каждого из них. И, если для каждого из них нужно лезь в базу и ждать оттуда данных, то общее время выполнения всех одновременных запросов будет равно максимальному времени выполнения одного запроса из всех одновременных. И, если БД тормозит, то сервак будет тормозить, он будет просто спать.
Я надеюсь, что ты понимаешь о чём пишешь и под словом "БД тормозит" подразумевал, что она не справляется с возросшим потоком запросов. В таком случае я не очень понимаю зачем вообще рассматривать подобный, очевидно аварийный сценарий, который однозначно закончится крахом системы (в такой ситуации наш сервер просто сдохнет от переполнения пула сопрограмм, ну или же начнёт посылать пользователей). И кстати не факт, что при этом сервер будет всё время спать — всё зависит от входящего потока запросов...
Я думаю, что надо всё же рассматривать нормальное функционирование системы, а не аварийное. Давай даже немного гиперболизируем ситуацию для ясности. Пускай у нас запросы весьма тяжёлые, но БД может справиться с любым их потоком (это решается тем самым масштабированием "тазиков", про которое ты так авторитетно заявлял в соседней темке). Т.е. пусть например каждый запрос к БД всегда (и при 1 клиенте и при 10 и при 100 и при 1000 и т.д.) исполняется за 10 секунд (такое вот экстремальное значение для ясности картины). Так чем по твоему будет определяться максимальное число одновременно обрабатываемых запросов на нашем сервере, работающем с такой "медленной" БД?
Здравствуйте, Skorodum, Вы писали:
S>Я про то, что все это, кроме удобства, доступно и в С или в "С++ с классами", шаблонная магия тут для удобства конечных пользователей.
Формально говоря да. Но лично я бы не взялся писать такое на чистом C, т.к. для такого же уровня оптимизации, потребовалось бы ручками выписывать каждую функцию под каждый тип — ну его нафиг, такие приключения... )))
_>Я надеюсь, что ты понимаешь о чём пишешь и под словом "БД тормозит" подразумевал, что она не справляется с возросшим потоком запросов.
Неправильно, это значит, что БД обрабатывает запрос долго и только. Например, для современных аналитических систем абсолютно нормально, когда чувак делает запрос на аналитику, выбирает галочки для фильтрации, и идёт ............ на кухню, идёт на долго. Это долго может измеряться часами. Это не потому-что софт неоптимальный, это потому-что данных для обработки и формирования аналитической выборки-петабайты. B те миллисекунды, на которые сервер более быстро ретранслирует ответ от БД наружу клиенту-эти милилсекунды потерются в общем времени выдачи данных как капля в океане.
