Здравствуйте, smeeld, Вы писали:
S>Нет количество одновременных запросов-это количество одновременных запросов. Время выполения каждого из них-это время выполнения каждого из них. И, если для каждого из них нужно лезь в базу и ждать оттуда данных, то общее время выполнения всех одновременных запросов будет равно максимальному времени выполнения одного запроса из всех одновременных. И, если БД тормозит, то сервак будет тормозить, он будет просто спать.
Давайте представим себе, что есть HTTP-сервер, на который раз в секунду приходит 1000 запросов. Эти запросы распределяются на 10 рабочих потоков (т.е. по 100 запросов на поток).
Допустим, в одном случае каждый рабочий поток тратит на всю обработку одного запроса, не считая времени работы БД, по 9ms.
А во втором случае каждый рабочий поток тратит на ту же самую обработку по 11ms.
Вопрос: как будет меняться длительность обработки запросов с течением времени в каждом из этих случаев?
Здравствуйте, alex_public, Вы писали:
_>Эм, ты давно видел скорости современных карт и скорости оперативной памяти? ))) Мы если что, не про твой старенький ноутбук, а про сервера... )
Вообще оптимизировать имеет смысл время отклика, в не время обработки запроса. Время отклика пользователю зависит и от сети(не у всех пока 10Гб интернет), и от диска(даже с SSD).
Серверный софт оптимизировать бесполезно, смысл есть в качественном ускорении в разы(вроде перехода Java->C++), но не в 20% которые ты получишь написав самые сложные шаблоны.
Даже допустим в браузере на С++ ты оптимизируешь движок допустим, это хорошо. Но javascript все равно все это съест. Лучше придумайте новый GUI по сети, напишите его на C с классами, и тогда пользователи заметят разницу.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, RussianFellow, Вы писали:
RF>И ещё вопрос: какие языки программирования популярны, востребованы в настоящее время?
Если кратко, то все. Но некоторые языки требуются вкупе с дополнительными знаниями. Если вы например хорошо строите мат. алгоритмы и знаете Rust, то вакансий море на огромные деньги (точнее, самих-то вакансий численно не много, но конкуренции там нет и вас с руками оторвут). То же самое с веб-сервисами и Go, графикой и С++; и т.д.
То есть если у вас есть доп. знания, выгодно _под них_ изучить язык, ибо такие сочетания ценятся.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, so5team, Вы писали:
S>Попробуйте воздержаться от своих оценочных суждений в адрес людей, которые здесь вообще не присутствуют
Попробуй не ходить со своими правилами в чужой монастырь. Мне жаль что я задел твои чувства к кумиру, но это не является оправданием твоему хамству.
S>Может тогда и разговор получится.
Не получится. Человек либо способен без личностей, либо нет. Остальное — отмазки.
Здравствуйте, alex_public, Вы писали:
_>Ну давай, расскажи во что же оно "упирается", если не в CPU.
В саму РСУБД, в память.
_>способных обработать любое число запросов
Так не бывает. При активной работе с БД она всегда самое слабое звено. Если же число запросов настолько мало, что это не так, то на генерацию таких запросов хватит копеечного кластера из пары самых дохлых мащин.
Здравствуйте, Skorodum, Вы писали:
Pzz>>Ну это при условии, что оно в CPU упрется. А не в диск, например, или в сеть. S>Все на одной машине, вся БД в памяти или рейд SSD, данные только читаются.
Нафига тогда вообще облако, если все на одной машине?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да, 2019 и такое позорище родом из 90-х, преподносимое каким то хипста-фриком.
Это если не вдаваться в суть написанного.
Там все примеры — по-сути кодогенератор.
Для шарпа аналогичное возможно или через динамическую генерацию кода, или внешнюю кодогенерирующую тулзину времени сборки.
... при том что ни один из существующих сегодня провайдеров линка не покрывает полной спеки экспрешенов.
А уже 2019-й...
Здравствуйте, Pzz, Вы писали:
_>>Ещё раз: что значит упирается? Чем меньше тиков процессора тратится на обработку одного запроса, тем больше одновременных запросов может обработать один сервер, тем меньше серверов надо оплачивать — прямая бизнес-выгода. Pzz>Ну это при условии, что оно в CPU упрется. А не в диск, например, или в сеть.
Чаще оно упирается в отсутствие необходимости линейного масштабирования, что само по себе усложняет систему многократно и делает её более тормознутой.
Там где пашет десяток явовских серверов приложений, там справляется одна железка на С++.
Здравствуйте, smeeld, Вы писали:
_>>Я правильно понимаю, что ты считаешь, что количество одновременных запросов, обрабатываемых сервером, определяется полным (включая сон) временем обработки одного запроса? S>Нет количество одновременных запросов-это количество одновременных запросов. Время выполения каждого из них-это время выполнения каждого из них. И, если для каждого из них нужно лезь в базу и ждать оттуда данных, то общее время выполнения всех одновременных запросов будет равно максимальному времени выполнения одного запроса из всех одновременных. И, если БД тормозит, то сервак будет тормозить, он будет просто спать.
Или обслуживать сотни тыщ одновременных запросов.
Тебе надо было внимательней прочитать вопрос, на который отвечаешь.
пользователь "Ночной Смотрящий" назвает "хипста-фриком" вполне конкретного человека
И? Я же не говорил ни про кого из собеседников, верно? А говорить про третьих лиц — так это тогда то же самое надо применять к Путину, Трампу, Навальному и т.п?
Но это все неважно. Потому что я не о каком то его физическом недостатке написал, не о его цвете кожи или разрезе глаз, что мерзко. Я написал о его сознательном выборе, отражающем его стиль мышления, и я не понимаю почему это вызывает у тебя такой баттхерт, что ты позволяешь себе прямо оскорблять собеседника.
Здравствуйте, vdimas, Вы писали:
V>Это если не вдаваться в суть написанного. V>Там все примеры — по-сути кодогенератор.
Да я понимаю. Речь то не про это, а про полученный результат.
V>... при том что ни один из существующих сегодня провайдеров линка не покрывает полной спеки экспрешенов.
Это даже теоретически невозможно, потому что linq имеет существенно большую мощность, чем sql. Можно, конечно, в памяти досчитывать, что некоторые провайдеры пытаются, но вреда от этого больше чем пользы. Намного правильнее материализовать то что есть, а потом допиливать результат уже обычным linq 2 objects.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Попробуйте воздержаться от своих оценочных суждений в адрес людей, которые здесь вообще не присутствуют
НС>Попробуй не ходить со своими правилами в чужой монастырь.
Во-первых, это где ваш монастырь?
Во-вторых, вы таки решитесь указать таймстемп на видео или номер слайда в презентации с "позорным" кодом?
НС>Не получится. Человек либо способен без личностей, либо нет. Остальное — отмазки.
Самокритично вы о себе. Вам же ничего не помешало перейти на обсуждение моей личности вместо обсуждения кода, который вы соизволили обозвать.
Здравствуйте, vdimas, Вы писали:
V>Там где пашет десяток явовских серверов приложений, там справляется одна железка на С++.
Много железок делают не только для перфоманса, но и для таких вещей как надежность или геораспределенность. Чуть менее чем у всех облачных проектов, которыми я занимался последние три года те машины, где идет активная работа с БД — это, как правило, 2-4 1-2 ядерных машины со средней загрузкой CPU 10-20%. На фоне кластеров в десятки многоядерных машин, которые как раз CPU bound и к БД почти не обращаются. И там, конечно, перформанс меппера из БД ну очень важен.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Это если не вдаваться в суть написанного. V>>Там все примеры — по-сути кодогенератор. НС>Да я понимаю. Речь то не про это, а про полученный результат.
В результате на бинарном протоколе примерно в сто раз меньшее потребление энергии (если прямой речью) при настолько же приятном внешнем использовании.
В том числе заслуга кодогенерирующих if constexpr, уменьшающих частоту сброса конвейеров процов.
В том числе показано сравнение синтаксиса С++03 vs более новых диалектов, где кое-какие навороты сократились до 3-х строк.
V>>... при том что ни один из существующих сегодня провайдеров линка не покрывает полной спеки экспрешенов. НС>Это даже теоретически невозможно, потому что linq имеет существенно большую мощность, чем sql.
1. Не реализованы даже те некоторые возможности, которые могли бы быть реализованы на диалекте, скажем, TSQL через батчи с промежуточными переменными.
2. Речь не только про SQL, теоретически есть возможность написать провайдер для сценариев linq to objects, подсунув соотв. контейнеры с подержкой IQueryable, где за счёт кодогенерации поиметь приличный буст на больших О. Потому что встроенный linq 2 objects, мягко говоря, не алё. Периодически его используем для написания кода, но в процессе профилирования из hot path всегда уходит. (Со своей сетевой либой на .Net Core подошли к 3-6 микросекундам на отклик, что сравнимо с плюсовыми реализациями, но из стандартной либы используется почти ничего, увы, даже парсинг чисел и дат + обратное преобразование в текст свои, бо на каждой такой операции разница в 3-5 раз в сравнении со встроенными даже самыми последними реализациями)
НС>Можно, конечно, в памяти досчитывать, что некоторые провайдеры пытаются, но вреда от этого больше чем пользы. Намного правильнее материализовать то что есть, а потом допиливать результат уже обычным linq 2 objects.
Ес-но.
Тут привычный размен скорости разработки на тиковыжимание.
От задач зависит...
И еще от масштабируемости решения — ради одноразовых сниппетов обычно напрягаться бессмысленно.
Но тот драйвер в докладе имеет относительно небольшой размер кодовой базы, при том что используется широко на "прикладном" уровне — вот и появляется смысл.
В нашей конторе тоже низкоуровневые самописные либы используются в нескольких десятках продаваемых продуктов и влияют на их характеристики.
Здравствуйте, smeeld, Вы писали:
_>>Я надеюсь, что ты понимаешь о чём пишешь и под словом "БД тормозит" подразумевал, что она не справляется с возросшим потоком запросов. S>Неправильно, это значит, что БД обрабатывает запрос долго и только. Например, для современных аналитических систем абсолютно нормально, когда чувак делает запрос на аналитику, выбирает галочки для фильтрации, и идёт ............ на кухню, идёт на долго. Это долго может измеряться часами. Это не потому-что софт неоптимальный, это потому-что данных для обработки и формирования аналитической выборки-петабайты. B те миллисекунды, на которые сервер более быстро ретранслирует ответ от БД наружу клиенту-эти милилсекунды потерются в общем времени выдачи данных как капля в океане.
Ууу какой запущенный случай. Т.е. вот ты реально считаешь, что если БД долго обрабатывает каждый запрос (но при этом может обрабатывать тысячи таких запросов одновременно), то сервер, работающий с ней, всегда будет большую часть времени "спать"? )))
Здравствуйте, lpd, Вы писали:
lpd>Вообще оптимизировать имеет смысл время отклика, в не время обработки запроса.
Оптимизация времени отклика — это удовлетворённость клиента.
Оптимизация времени обработки запроса — это уменьшение расходов на инфраструктуру.
Я думаю важно и то и другое. )
lpd>Серверный софт оптимизировать бесполезно, смысл есть в качественном ускорении в разы(вроде перехода Java->C++), но не в 20% которые ты получишь написав самые сложные шаблоны.
Ну вот лично я и не оптимизирую. Потому что у моих сайтов (в смысле где владелец) нагрузка такая, что хватает даже кода на Питоне (который продуктивнее для разработки). А вот у Яндекса ситуация с нагрузкой совсем другая и им очевидно очень полезно оптимизировать свой серверный софт, что они и делают (ведя разработку на современном C++).
lpd>Даже допустим в браузере на С++ ты оптимизируешь движок допустим, это хорошо. Но javascript все равно все это съест. Лучше придумайте новый GUI по сети, напишите его на C с классами, и тогда пользователи заметят разницу.
_>Ууу какой запущенный случай. Т.е. вот ты реально считаешь, что если БД долго обрабатывает каждый запрос (но при этом может обрабатывать тысячи таких запросов одновременно), то сервер, работающий с ней, всегда будет большую часть времени "спать"? )))
Если все запросы поступят одновременно, то промежуточный сервак зависнет на время отклика БД. Если запросы будут "размазаны" во времени, то спать промежуточный сервак не будет, одни запросы будут приниматься, другие ждать ответа, третьи отдаваться etc. Основной посыл у меня в том, что те миллисекунды, за которые промежуточный сервак исполнит свою часть работы быстрее, чем если софт на нём будет на какой-нибудь Java (что на порядки чаще в тырпрайзах встерчается чем на C++, С++ там вообще редкость, на которую пальцем показывают), то это никак на общую картину работы всей системы клиенты<->микросервисы<->базы не повлияет.
И неспроста . Без бэкенда, видимо, не обойтись, если нужна кроссплатформенность.
Pzz>Ну никто и не предполагает, что на этом ассемблере можно руками написать программу, которая без изменений будет работать на разных архитектурах.
Гм, а я так и думал :D. Но мне простительно, в низком уровне понимаю мало.
. Без бэкенда, видимо, не обойтись, если нужна кроссплатформенность.