Здравствуйте, netch80, Вы писали:
НС>>Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику. N>Доказательства будут?
Того что в статье по ссылке в стартовом сообщении недостаточно?
если бы шмыга не сидел и не генерил бессмысленные набросы на ктыве
он бы эту статью еще на конфе в ютубе посмотрел год или два назад
по теме
тот лузер который комментировал что у него что то тормозит
должен был привести пруфы что у него QUIC включился в броузере
я почти уверен что он у него он не включился и фоллбек закинул его обратно в http2 в лучшем случае
а то и в http1.1
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это так не работает. Нет, тут именно хороший технический бэкграунд и очень плохое взаимодействие с продактами. Чего то там наоптимизировали, получили отличные циферки, подстелили вумные исследования про латентность, а вот про продукт свой забыли.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, netch80, Вы писали:
НС>>>Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику. N>>Доказательства будут?
НС>Того что в статье по ссылке в стартовом сообщении недостаточно?
Возможно не в каждом случае, но на моих данных msgpack давал прирост в распаковке и упаковке сообщения в нужную мне структуру солидный процент. По размеру msgpack весил где-то на 12...15% меньше.
Плюсовое окружение: gcc 8.3, rapidjson с insitu для распаковки, msgpack-c.
Здравствуйте, Sazon, Вы писали:
S>Возможно не в каждом случае, но на моих данных msgpack давал прирост в распаковке и упаковке сообщения в нужную мне структуру солидный процент. По размеру msgpack весил где-то на 12...15% меньше.
По ссылки 10%. И? Что это за продукт, где 10% трафика настолько критично, что оправданно пойти на усложнение и клиентов и сервера?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sazon, Вы писали:
S>>Возможно не в каждом случае, но на моих данных msgpack давал прирост в распаковке и упаковке сообщения в нужную мне структуру солидный процент. По размеру msgpack весил где-то на 12...15% меньше.
НС>По ссылки 10%. И? Что это за продукт, где 10% трафика настолько критично, что оправданно пойти на усложнение и клиентов и сервера?
Да, по памяти не так и много, но по сериализации и десериализация цифры имеют иной порядок, по крайней мере в моем случае.
Здравствуйте, Sazon, Вы писали:
НС>>По ссылки 10%. И? Что это за продукт, где 10% трафика настолько критично, что оправданно пойти на усложнение и клиентов и сервера? S>Да, по памяти не так и много, но по сериализации и десериализация цифры имеют иной порядок
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sazon, Вы писали:
НС>>>По ссылки 10%. И? Что это за продукт, где 10% трафика настолько критично, что оправданно пойти на усложнение и клиентов и сервера? S>>Да, по памяти не так и много, но по сериализации и десериализация цифры имеют иной порядок
НС>Иной порядок это 100%? Серьезно?
На некоторых данных в районе 200%. Речь об объектах с одним уровнем, значения которых принадлежат строковому типу в основном.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Иной порядок это 100%? Серьезно?
Из того что я лично видел сериализация в текст + LZ выходила примерно в 2.5 раза медленнее сериализации в бинарь без лишних телодвижений, итоговый размер сравним.
Здравствуйте, Sazon, Вы писали:
S>На некоторых данных в районе 200%. Речь об объектах с одним уровнем, значения которых принадлежат строковому типу в основном.
Даже не представляю где можно было на строке столько сэкономить. Даже если использовать однобайтовые кодировки для русского текста, все равно эта разница после сжатия практически полностью нивелируется. Чтобы получить 100% разницы надо либо убрать какой то объемный шум с высокой энтропией, либо речь идет про сверхкороткие сообщения. Но для сверхкоротких сообщений надо и HTTP на что то другое поменять.
Здравствуйте, CreatorCray, Вы писали:
НС>>оправданно пойти на усложнение и клиентов и сервера? CC>Какое усложнение? Сериализатор поменять?
А если клиентов несколько типов на разных языках и платформах? А если часть клиентов на JS (gzip и json там искаропки, а вот кастомные штуки придется выпиливать руками на самом JS)? Что насчет версионирования и багов в клиентских библиотеках, или фичабагов, которые делают реализации немножечко отличающимися по поведению?
Кастомная сериализация это таки вполне объемный функционал, причем находящийся в месте, которое наиболее болезненно в плане изменений. Так что если уж ее использовать, то должны быть железобетонные бенефиты для продукта, а не -10% трафика. О чем в статье прямо и сказано.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sazon, Вы писали:
S>>На некоторых данных в районе 200%. Речь об объектах с одним уровнем, значения которых принадлежат строковому типу в основном.
НС>Даже не представляю где можно было на строке столько сэкономить. Даже если использовать однобайтовые кодировки для русского текста, все равно эта разница после сжатия практически полностью нивелируется. Чтобы получить 100% разницы надо либо убрать какой то объемный шум с высокой энтропией, либо речь идет про сверхкороткие сообщения. Но для сверхкоротких сообщений надо и HTTP на что то другое поменять.
Причем тут http и сжатие. Я сугубо про упаковку и распаковку некого key/value набора. Как он там передается или читается из файла, это отдельный вопрос. Сообщение несколько Кб, число key/value пар от 20...60., не знаю, короткие или нет. Например, в msgpack строчка хранится с длиной, что уже дает свой профицит.
Здравствуйте, Sazon, Вы писали:
S>Причем тут http и сжатие. Я сугубо про упаковку и распаковку некого key/value набора.
При том что я как раз про то и пишу, что бессмысленно оптимизировать циферки в отрыве от продукта. Твои 12-15% круто выглядят только когда мы искусственно изолируемся от продукта. А когда все это выразить в терминах бенефита, который получают конкретные кастомеры — вот тут часто все становится не так очевидно.
Здравствуйте, netch80, Вы писали:
N>В CBOR после начального деления на major и minor type всё банально и реально достаточно эффективно (начиная уже с выноса мелких констант в отдельные типы), народ проделал серьёзную работу по изучению реальных данных в Сети и поиску оптимальных методов кодирования. При этом в отличие от PER (но аналогично BER) не потеряны типы данных (хотя бы частично), что позволяет определять заметный класс ошибок передачи.
Угу, DER-кодирование тоже позволяет поисследовать поток.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво. НС>Серьезно? Тогда можно смело в помоечку.
Версионность отдана на прикладной уровень.
Например, версионность хорошо работает в PFX, P12 и прочих ASN.1 контейнерах X509 ключей/сертификатов.
Если бы воткнули версионность прямо в стандарт, было бы гирей на ногах.
Здравствуйте, Ночной Смотрящий, Вы писали:
K>>А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором НС>Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику.
Насчёт MessagePack не знаю, но на практике разница в затратах на кодирование/раскодирование текстовых и бинарных сообщений в области HFT более порядка.
Бинарные протоколы обычно проще текстовых в обслуживании, т.е. в прикладном коде, потому что типобезопасны, плюс стадия "маппинга" отсутствует за ненадобностью.
В любом случае, "лёгкость" использования того или иного протокола определяет наличие соотв. инфраструктуры/библиотек и продуманность их АПИ. Мы же не вчера все родились, тут все прекрасно понимают, что выбор в пользу плохого/медленного решения обычно приходится делать в гетерогенной среде, где не для всех используемых технологий есть сравнимое по кач-ву покрытие. ))
Здравствуйте, vdimas, Вы писали:
N>>>3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво. НС>>Серьезно? Тогда можно смело в помоечку. V>Версионность отдана на прикладной уровень.
Если у тебя нижний уровень неверсионный, никакой прикладной ситуацию не исправит, максимум набор костылей будет. Вот наоборот, сломать версионность на прикладном уровне — это запросто.
