Здравствуйте, vdimas, Вы писали:
V>Насчёт MessagePack не знаю, но на практике разница в затратах на кодирование/раскодирование текстовых и бинарных сообщений в области HFT
Ключевой момент я выделил.
V>Бинарные протоколы обычно проще текстовых в обслуживании, т.е. в прикладном коде, потому что типобезопасны
Типобезопасность не зависит от бинарности протокола.
V>В любом случае, "лёгкость" использования того или иного протокола определяет наличие соотв. инфраструктуры/библиотек и продуманность их АПИ.
Вот именно, наличие инфраструктуры. Особенно если клиент в браузере.
Здравствуйте, vsb, Вы писали:
vsb>Ну не знаю, что там в Калифорнии. У меня в деревне дом, там 4G даёт 10-50 мегабитов. И пинг вполне пристойный. Думаю, у большинства людей так. Оптимизируют под большинство.
Сегодня в Москве занимался упражнением: правильно сориентируй и подними на правильную высоту телефон, чтобы хоть как-то за инет зацепился на несколько секунд.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Если у тебя нижний уровень неверсионный, никакой прикладной ситуацию не исправит, максимум набор костылей будет.
Или не будет, если версионность не требуется.
НС>Вот наоборот, сломать версионность на прикладном уровне — это запросто.
Звучит так, будто обеспечение версионности — это бог весть какая сложность.
Версионность на прикладном уровне хороша тем, что её можно организовать произвольно в угоду прикладных задач.
Например, воткнуть версионность в типы как структур верхнего уровня, так и вложенных структур, как оно есть в запросах-ответах семейства SSL-протоколов.
Т.е. в реальном SSL-трафике протокольного уровня живёт комбинаторика независимых "версионностей".
Как такое было предусмотреть на системном уровне? — ХЗ, удовлетворительного ответа здесь точно нет.
Здравствуйте, Ночной Смотрящий, Вы писали:
V>>Насчёт MessagePack не знаю, но на практике разница в затратах на кодирование/раскодирование текстовых и бинарных сообщений в области HFT НС>Ключевой момент я выделил.
Ключевое там тщательное измерение затрат, вместо насасывания их из пальца.
V>>Бинарные протоколы обычно проще текстовых в обслуживании, т.е. в прикладном коде, потому что типобезопасны НС>Типобезопасность не зависит от бинарности протокола.
Таки, бинарные и околобинарные протоколы (типа FIX), имеют хоть какие-то встроенные ср-ва контроля как целостности, так и корректности структуры сообщений.
Из мейнстримовых human-readable форматов на ум приходит только XML в связке со строгой схемой.
И в любом случае контроль целостности придётся навертеть на прикладном уровне.
V>>В любом случае, "лёгкость" использования того или иного протокола определяет наличие соотв. инфраструктуры/библиотек и продуманность их АПИ. НС>Вот именно, наличие инфраструктуры. Особенно если клиент в браузере.
Звучит как "последний козырь".
Клиент в браузере — это ж обычно верхушка айсберга.
Да и передают туда в современных приложухах разве что инфу для полей GUI при обновлении данных, т.е. непонятно что тут обсуждать, когда основная работа выполняется не на клиенте.
L>>Я так понял, они буквально за десятки байт борются. _>это как раз признак того что оптимизируют не то и не там
Это признак попыток разделить работу на команды. В одной команде работают сильные специалисты. Они могут создать решения, которые экономят 10% здесь, 20% там, и эта работа выливается в экономию петабайтов трафика и кило-серверов.
Но такая команда одна. Потому что эти специалисты — штучный товар. Нет никаких шансов набрать десять таких команд, их попросту и нет в таком количестве.
Поэтому на базе такой инфраструктуры работают десятки и сотни команд, которые вообще не думаю про оптимизацию. Ничтоже сумняшеся, они запилят N^2 сортировку, и влегкую запилят структуры с ужасными характеристиками по памяти. Потому что не знают. И сделают leaky API, так что другие команды напишут свой код в предположении, что именно эта неэффективная структура используется (тем самым навеки скрепят применение этой структуры). Все это потом завернут в еще один уровень, чем достигнут N^4 и даже более интересные асимптоты.
Стоимость расчистки этих авгиевых дворцов настолько высока, что дешевле потребовать от занимающихся оптимизацией специалистов "придумать что-нибудь этакое". Вот они и придумывают. Потом публикуют статьи, которые после и триггерят вот такие треды
А то что проблема создана путем набора программистов низкой квалификации — так то бизнес, ничего личного. В конце концов, если б не говнокодеры, это ж сколько возможностей сразу исчезло бы у оптимизаторов.
Здравствуйте, vdimas, Вы писали:
НС>>Если у тебя нижний уровень неверсионный, никакой прикладной ситуацию не исправит, максимум набор костылей будет. V>Или не будет, если версионность не требуется.
Практика показывает, что как только мы выходим за рамки одного процесса, то рано или поздно версионность начинает требоваться примерно всегда.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Практика показывает, что как только мы выходим за рамки одного процесса, то рано или поздно версионность начинает требоваться примерно всегда.
И даже в этом случае на системном уровне версионность избыточна.
Просмотри существующие различные прикладные протоколы, хосподя.
На практике версию протокола или список поддерживаемых версий вставляют в условные client-hello и server-hello сообщения.
Далее обмен сообщениями обычно идёт без указания версий, бо версия протокола была выбрана при установке связи.
Здравствуйте, SkyDance, Вы писали:
L>>>Я так понял, они буквально за десятки байт борются. _>>это как раз признак того что оптимизируют не то и не там
SD>Это признак попыток разделить работу на команды. В одной команде работают сильные специалисты. Они могут создать решения, которые экономят 10% здесь, 20% там, и эта работа выливается в экономию петабайтов трафика и кило-серверов.
+1
очень даже может быть
SD>Но такая команда одна. Потому что эти специалисты — штучный товар. Нет никаких шансов набрать десять таких команд, их попросту и нет в таком количестве.
SD>Поэтому на базе такой инфраструктуры работают десятки и сотни команд, которые вообще не думаю про оптимизацию. Ничтоже сумняшеся, они запилят N^2 сортировку, и влегкую запилят структуры с ужасными характеристиками по памяти. Потому что не знают. И сделают leaky API, так что другие команды напишут свой код в предположении, что именно эта неэффективная структура используется (тем самым навеки скрепят применение этой структуры). Все это потом завернут в еще один уровень, чем достигнут N^4 и даже более интересные асимптоты.
SD>Стоимость расчистки этих авгиевых дворцов настолько высока, что дешевле потребовать от занимающихся оптимизацией специалистов "придумать что-нибудь этакое". Вот они и придумывают. Потом публикуют статьи, которые после и триггерят вот такие треды SD>А то что проблема создана путем набора программистов низкой квалификации — так то бизнес, ничего личного. В конце концов, если б не говнокодеры, это ж сколько возможностей сразу исчезло бы у оптимизаторов.
ну дык, как я и написал "оптимизируют не то и не там"
_>ну дык, как я и написал "оптимизируют не то и не там"
Будь уверен, они тоже это понимают.
Но от команды специалистов требуют и ждут публикаций, это часть их рабочих обязанностей (по поддержке силы бренда). Вот тем и приходится натягивать улыбку и писать про оптимизации там, где улучшения будут на проценты (причем частенько за счет усложнения, что всегда плохо). Но чтоб сделать улучшения на порядки нужны радикальные меры. В теории, требуемый эффект достигается заменой тысяч низкоквалифицированных на десятки высококвалифицированных. На практике это невозможно в силу отсутствия этих самых десятков в одном географическом месте. Благодаря КОВИДу этот барьер может быть слегка порушен, и (опять же в теории) можно представить кого-то из монстров ИТ занимающихся именно таким хед-хантингом в планетарных масштабах. На практике же это разве что в долгосрочной перспективе возможно (слишком велики силы инерции, слишком уж не хочется платить сильному спецу в России деньги, которые он может получить в Лондоне или Нью-Йорке).
Здравствуйте, SkyDance, Вы писали:
SD>Это признак попыток разделить работу на команды. В одной команде работают сильные специалисты. Они могут создать решения, которые экономят 10% здесь, 20% там, и эта работа выливается в экономию петабайтов трафика и кило-серверов.
Вот соглашусь. Когда вконтакт еще был дуровским, я анализировал его джаваскрипт, чтобы понять,как пишут эффективные сайты. Что я могу сказать — код был "олимпиадным" в плане именования сущностей и декомпозиции, но его было немного и он был эффективен, и немало труда было вложено в компактность, динамическую подгрузку и скорость отрисовки. Уверен, писала его математически продвинутая молодежь под надзором сильных архитекторов.
Кеширование помогло нам снизить показатель RPS с 1 млн до 160 тысяч. Немного легче, но 160 тысяч фотографий в секунду всё равно нужно как-то перекодировать, причём желательно подгоняя под разрешение экрана. Этим занимается небольшой кластер из GPU и FPGA.
Зачем? Задача естественным образом параллелится на десятки миллионов клиентов — почему бы не нагрузить их? Что стянул — то и перекодировал, при отсутствии WebP в хранилище, и отдал обратно. Да, это создаст всплеск обратного трафика от клиентов к серверам, но на хостинг-площадках входящий трафик как правило не тарифицируется. Даже у сверхжадного амазона. Да и всплеск этот со временем спадёт, как только наиболее востребованные и часто запрашиваемые изображения будут перекодированы.
SE>Кеширование помогло нам снизить показатель RPS с 1 млн до 160 тысяч. Немного легче, но 160 тысяч фотографий в секунду всё равно нужно как-то перекодировать, причём желательно подгоняя под разрешение экрана. Этим занимается небольшой кластер из GPU и FPGA.
SE>Зачем? Задача естественным образом параллелится на десятки миллионов клиентов — почему бы не нагрузить их? Что стянул — то и перекодировал, при отсутствии WebP в хранилище, и отдал обратно. Да, это создаст всплеск обратного трафика от клиентов к серверам, но на хостинг-площадках входящий трафик как правило не тарифицируется. Даже у сверхжадного амазона. Да и всплеск этот со временем спадёт, как только наиболее востребованные и часто запрашиваемые изображения будут перекодированы.
N>Секьюрити. Накодируют тебе дикпиков, потом разбирайся.
Аргумент, да. А сверка охренниардов webp с оригиналами в jpg — тоже то ещё пожиралово серверных ресурсов.
