Чел. долго описывает, как благодаря пережатию картинок из JPEG в WebP, использованию HTTP3/QUIC, использованию новых алгоритмов сжатия, бинарному протокола вместо JSON — смогли сэкономить немало трафика и вообще все куль, победа.
Еще порадоволо прямо детективное разбирательство с сетевыми тормозами и как выход — использовать BBR.
Но как всегда все обломал коммент от мудреца:
>Как мы отказались от JPEG, JSON, TCP и ускорили ВКонтакте в два раза
Как пользователь я вижу скорее обратную ситуацию: вконтакт всё сильнее тормозит, особенно на нестабильном соединении. 20 мегабайт скриптов, которые грузятся 2 минуты, это совсем зашквар. Не в том месте вы оптимизируете
S>Но как всегда все обломал коммент от мудреца:
S>
S>>Как мы отказались от JPEG, JSON, TCP и ускорили ВКонтакте в два раза
S>Как пользователь я вижу скорее обратную ситуацию: вконтакт всё сильнее тормозит, особенно на нестабильном соединении. 20 мегабайт скриптов, которые грузятся 2 минуты, это совсем зашквар. Не в том месте вы оптимизируете
Охотно верю, что олимпиадникам удалось по своей части что-то оптимизировать и даже получить заметный прирост в скорости (если мерить мгновенную скорость загрузки чего-нибудь).
Но дебильный дизайн с кучей говноскриптов может запросто свести на нет все их усилия.
Конкретно про ВКонтакте не знаю, не пользуюсь, но аналогичный яркий пример — Сбербанк-Онлайн. До редизайна был простеньким, но удобным, после — стал навороченным и ублюдочным.
Здравствуйте, klopodav, Вы писали:
K>Охотно верю, что олимпиадникам удалось по своей части что-то оптимизировать и даже получить заметный прирост в скорости (если мерить мгновенную скорость загрузки чего-нибудь). K>Но дебильный дизайн с кучей говноскриптов может запросто свести на нет все их усилия.
Здравствуйте, Shmj, Вы писали:
S>Статья: https://habr.com/ru/company/vk/blog/594633/
Что значит не в том месте оптимизируете?
Для компании важно минимизировать трафик, ибо за него приходится платить плюс необходимо минимизировать количество серверов, за которое тоже придется платить. Что там у пользователя — нищеброда, который сейчас сидит на компе 20 летней давности или мобиле за 3000 рублей с мегабайтом оперативки не волнует, если пользователь настолько нищеброд что для него 10 000р на не тормозящий телефон большие деньги, от него будут одни расходы, а не прибыль.
Здравствуйте, vsb, Вы писали:
vsb>Нет, обычный слабенький десктоп с Win 10.
Ясно. Я к тому, что у доброй половины аудитории VK, наверное, бюджетные смартфоны со слабеньким ЦП, который долго и мучительно парсит мегабайты (сотни килобайт?) JavaScript-кода....
Здравствуйте, Lazytech, Вы писали:
vsb>>Нет, обычный слабенький десктоп с Win 10.
L>Ясно. Я к тому, что у доброй половины аудитории VK, наверное, бюджетные смартфоны со слабеньким ЦП, который долго и мучительно парсит мегабайты (сотни килобайт?) JavaScript-кода....
Так на смартфоны ставят приложение. Не знаю, на чём оно написано и даже не пользовался им никогда, так что комментировать не могу.
WebP замыливает фотографии, так что не самая лучшая "оптимизация".
А насчёт JSON->Messagepack я вообще не понял смысла. Что мешало тот же самый JSON хранить сжатым gzip-ом? А при передаче по сети JSON сожмётся веб-сервером.
Здравствуйте, L.K., Вы писали:
LK>А насчёт JSON->Messagepack я вообще не понял смысла. Что мешало тот же самый JSON хранить сжатым gzip-ом? А при передаче по сети JSON сожмётся веб-сервером.
Я так понял, они буквально за десятки байт борются.
я пел оды движку RSDN. Обычно, если я делаю комплименты, это завуалированное злоехидство. (Вот такой я человек. Мне стыдно (нет)).
В том случае мой постинг был написан на следующий день после того, как команда Хабра отчиталась о новых оптимизациях в движке. С каждой их оптимизацией тормозит всё адовее и адовее. После последней оптимизации страница просто закрывает браузер через раз на слабом тестовом мобильном устройстве. Ибо память. Я всё жду Финальной Оптимизации, после которой сайт на этом устройстве сразу после открытия будет вырубать браузер.
А движок RSDN, при том, что в своё время его только ленивый не пинал ногами за отсутствие мобильной оптимизации, на его фоне выглядит конкретным молодцом. Секрет успеха прост: не менять код лет пятнадцать, а закон Мура сделает остальное. И ты ещё увидишь, как по реке плывут трупы других сайтов.
Просто вы хорошо думаете о людях. Вы думаете, это олимпиадники, не набравшиеся мудрости. А я думаю, они достаточно мудры, чтобы за свою деструктивную деятельность получать очень хорошие деньги, да ещё и чесать своё эго и учить нас жизни в своих статьях.
Здравствуйте, elmal, Вы писали:
E>Что значит не в том месте оптимизируете? E>Для компании важно минимизировать трафик, ибо за него приходится платить плюс необходимо минимизировать количество серверов, за которое тоже придется платить.
О да. Все эти компании такие бедные, такие бедные, что когда они свою говноаналитку пихают за кулисы на каждый первый сайт (где ей делать, по-хорошему, вообще нечего), то потом просто столько платят за трафик и сервера, что еле концы с концами сводят и плачут горькими слезами. А садовнику у них в этом году пришлось остаться без крафтового смузи.
И, кстати. Они там на лету каждую секунду 160 тысяч (после кеширования, а до него было под лям) джипегов конвертят, для чего выделили и создали спецкластер. Он, наверно, стоит как «Союз-Аполлон», при нынешних-то ценах на майнинго-пригодное железо. Вы думаете, что трафло дороже? Сомневаюсь я.
Здравствуйте, Shmj, Вы писали:
S>Чел. долго описывает, как благодаря пережатию картинок из JPEG в WebP, использованию HTTP3/QUIC, использованию новых алгоритмов сжатия, бинарному протокола вместо JSON — смогли сэкономить немало трафика и вообще все куль, победа.
Это невероятно. Детишки вспомнили про бинарные протоколы. Неужели они и ASN.1 с пыльной полки вытащат?
Здравствуйте, Kernan, Вы писали:
S>>Чел. долго описывает, как благодаря пережатию картинок из JPEG в WebP, использованию HTTP3/QUIC, использованию новых алгоритмов сжатия, бинарному протокола вместо JSON — смогли сэкономить немало трафика и вообще все куль, победа. K>Это невероятно. Детишки вспомнили про бинарные протоколы. Неужели они и ASN.1 с пыльной полки вытащат?
ASN.1 был пионерской разработкой. Это подвиг, но много моментов решено неоптимально. Крайне сложный язык описания структур, неэффективные кодировки в двоичку, и всё такое.
Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. Текстовое представление почти полностью соответствует JSONʼу, то есть понятно всем по современным подходам.
Но всё же, как сказал ТС, люди занимаются фигнёй вместо главного...
Здравствуйте, Hobbes, Вы писали:
K>>Неужели они и ASN.1 с пыльной полки вытащат?
H>ASN.1 сложно и непонятно. Есть же protobuf.
У них разные подспециализации. protobuf предельно эффективен в случае, если у структуры с, например, до 100 записей обычно присутствуют не больше 10. Если должны быть все, то у него эффективность заметно падает. Многоуровневые структуры тоже не лучше, чем в конкурентах типа JSON и ASN.1.
ASN.1 несложен, если перевести с языка ISO. Ну и компиляторы схем надо бы сделать не только для 5-10 основных языков.
Вообще аналогов сейчас до чёрта, я вот прямо сейчас YANG мучаю по работе...
Здравствуйте, netch80, Вы писали:
N>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER.
Так есть же PER.
Вот что есть в ASN.1, а больше я нигде не видел, это constraints. Хотя бы constrained integer и его представление в PER — гениально. Но хипстерам сложно.
P. S. Всё же про ASN.1 надо учитывать, что его делали связисты, а не кодеры. Вот посмотрите на HTTP — его делали кодеры. Зато можно подключиться к HTTP серверу телнетом и чего-то там напечатать.
Здравствуйте, Hobbes, Вы писали:
H>Вот посмотрите на HTTP — его делали кодеры.
И он ужасен
H> Зато можно подключиться к HTTP серверу телнетом и чего-то там напечатать.
И никто так не делает а все берут хотя бы curl
Здравствуйте, netch80, Вы писали:
N>ASN.1 был пионерской разработкой. Крайне сложный язык описания структур, неэффективные кодировки в двоичку, и всё такое.
Он крайне сложный только для тех кто не знаком с матчастью теории компиляторов. Понятно, что АСН.1 был создан под задачи того времени и людьми которые были в наличии, а это были не самые плохие спецы . Кроме BER есть PER где упаковка идёт на битовом уровне, поэтому там была нужна эффективность, её можно было использовать.
N>Это подвиг, но много моментов решено неоптимально.
Например?
N>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. Текстовое представление почти полностью соответствует JSONʼу, то есть понятно всем по современным подходам.
Возможно, будущий кандидат для замены json. Хотя у нас всегда был бинарный xml как бы сам xml ненавидели.
N>Но всё же, как сказал ТС, люди занимаются фигнёй вместо главного...
А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором. Сразу все вспомнят как деды проектировали системы, про бинарные протоколы, про CORBA, и про другие технологии переосмыслив их в текущих реалиях лишь бы уменьшить нагрузку на железо, трафик и управление системами. Это же надо, люди когда-то боролись с оверхедом IP заголовков придумав ROHC но всё про##&*@ тупо добавив текст во всех протоколах выше транспорта.
Here’s an article on GigaOm from 2012 titled "The Growing Epidemic of Page Bloat". It warns that the average web page is over a megabyte in size.
The article itself is 1.8 megabytes long.
Here's an almost identical article from the same website two years later, called “The Overweight Web". This article warns that average page size is approaching 2 megabytes.
That article is 3 megabytes long.
If present trends continue, there is the real chance that articles warning about page bloat could exceed 5 megabytes in size by 2020.
И ведь угадал.
На самом деле, в этом бы не было проблемы, если бы за этим стоял прогресс. Если бы читать становилось удобнее. Как-то. (Но как можно сделать чтение статей более удобным? Это то, про что автор говорит: “This talk isn't about any of those [big websites packed with images <…> or well-designed web apps]. It's about mostly-text sites”). Но эти ресурсы же идут на гидратацию, например. Которая, как бы, экономит ресурсы. Но в реальности ресурсы не экономятся, а что касается удобства, я бы вырвал рученьки тому, кто её придумал. Потом, ресурсы идут на аналитику. Ну, тут uBlock Origin нам в помощь? Потом ресурсы идут на хрен пойми что. Но я не до конца дочитал.
P.S. И про Medium в точку. Вот его я как раз вспоминал много раз в связи с этим всем. Я даже так рискну обобщить: они все идут по дорожке «браузер в браузере». Своя загрузка, своя обработка всего и вся. Опять же, он там намекает, что медиумы сознательно это делают, в общем, пошёл я дочитывать.
Здравствуйте, Hobbes, Вы писали:
N>>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. H>Так есть же PER.
Теперь сравниваем PER, который сложен даже просто чтобы понять описание (я когда-то понял — но всё забыл и мне теперь придётся, если потребуется, перечитывать его заново), и CBOR. Сравнение ой не в пользу PER.
В CBOR после начального деления на major и minor type всё банально и реально достаточно эффективно (начиная уже с выноса мелких констант в отдельные типы), народ проделал серьёзную работу по изучению реальных данных в Сети и поиску оптимальных методов кодирования. При этом в отличие от PER (но аналогично BER) не потеряны типы данных (хотя бы частично), что позволяет определять заметный класс ошибок передачи.
H>Вот что есть в ASN.1, а больше я нигде не видел, это constraints. Хотя бы constrained integer и его представление в PER — гениально. Но хипстерам сложно.
Я не хипстер, но мне тоже сложно (PER в целом, продираться заново сквозь стиль описания).
Но я сейчас открыл эту секцию и не вижу ничего "гениального":
1. Оно зависит от lower bound и upper bound. А теперь что если у параметра допустимые значения, например, 0, 22, 31 и 45? Его можно впихнуть в 2 бита, но по этому описанию потребуется 6.
(Это не искусственно придуманный случай. Я сейчас такие штуки вижу в реальном проекте. Там не так растянуто, конечно, но есть в одном месте, например, из ~30 возможных чисел допустимо только 10.)
2. Весь алгоритм это просто выбор между: <8 бит, 8, 16, больше. Извините, это банальность, а не гениальность.
(Или я не то смотрю? Пункт 10.5.)
3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво. Если было допустимо, например, 0..50 (температура воздуха для тропиков), а для умеренных широт добавили до -30 снизу — всё, lb поменялся, плавного перехода не будет.
H>P. S. Всё же про ASN.1 надо учитывать, что его делали связисты, а не кодеры. Вот посмотрите на HTTP — его делали кодеры. Зато можно подключиться к HTTP серверу телнетом и чего-то там напечатать.
Любую двоичку ты не напечатаешь телнетом. Тем не менее, как видим по всей теме, временами она очень нужна.
А HTTP делали не кодеры, а высоколобые грамматисты — причём того стиля, который не укладывается в стандартные в остальном мире грамматические подходы. Я парсил SIP (идентичен по стилю и почти по деталям), это не укладывается в привычные LL/LR, по факту это нерекурсивный PEG на классах символов. Кодеры бы такое не придумали.
S>The article mentions that Google was able to boost user engagement in Google Maps by reducing the page weight from 100KB to 80KB.
S>Э-э?.. Только что проверил, чуть меньше шести метров. Просто google.com/maps, гугл-эккаунта у меня нет, масштаб всей Земли.
Это ж про google maps образца 2006 года. Возможно это даже про тогдашнюю мобильную версию речь.
The performance of websites and the impact that has, has been well documented over the years. In 2007 Amazon reported that for every 100 ms increase in load time of Amazon.com their sales decreased by 1%. Google also reported similar results in 2006 with their Google Maps product. Google found that by reducing the size of the page from 100KB to 80KB, their traffic shot up by 10% in the first week and then 25% in the following three weeks.
Здравствуйте, Kernan, Вы писали:
N>>ASN.1 был пионерской разработкой. Крайне сложный язык описания структур, неэффективные кодировки в двоичку, и всё такое. K>Он крайне сложный только для тех кто не знаком с матчастью теории компиляторов.
Я сейчас не найду ссылок, но авторитетно утверждалось, что даже с инструментальными средствами компиляции были заметные проблемы работы с ним.
Далее, затраты кода и памяти на полную реализацию были неподъёмны для большей части потенциальных применений 80-х и начала 90-х.
Коммерческие реализации стоили безумных денег. Свободные реализации только начинались и были багованными. Сейчас есть более-менее нормальные реализации, но это ж сейчас, когда ресурсов в ~1000 раз больше.
Ну а "матчасть теории компиляторов" в полном объёме и сейчас мало кому понятна.
K> Понятно, что АСН.1 был создан под задачи того времени и людьми которые были в наличии, а это были не самые плохие спецы .
Внизу — может быть. Вверху — ой нет, или по крайней мере они решали не задачу сделать эффективное решение, а — сделать своё решение и необязательно дёшево ;\
K> Кроме BER есть PER где упаковка идёт на битовом уровне, поэтому там была нужна эффективность, её можно было использовать.
И она включает жёсткую зависимость от наличия схемы и её согласованности между всеми участниками.
BER гибче, SNMP разбирается вообще без схемы, на интуиции — почему он оказался в итоге чуть ли не единственным приложением ASN.1, которое стало массовым. (X.509 это заметно позже, и там тоже BER (в виде DER), но не PER.)
N>>Это подвиг, но много моментов решено неоптимально. K>Например?
В CBOR видно, что целые до ±31 представляются одним байтом. Это очень частый случай и он оптимизирован. BER требует 3 байт на такое. PER — один байт или меньше, но тип при этом не указан, получается жёсткая зависимость от согласованности схемы. Много других аналогичных оптимизаций CBOR на сокращение объёма представления в полтора-два раза, при сохранении указания типа данного, для корректной синхронизации и полиморфизма.
N>>Если говорить о чём-то современном близкого типа, то это CBOR. У него плотность представления в двоичке выше раза в два, чем у BER. Текстовое представление почти полностью соответствует JSONʼу, то есть понятно всем по современным подходам. K>Возможно, будущий кандидат для замены json. Хотя у нас всегда был бинарный xml как бы сам xml ненавидели.
N>>Но всё же, как сказал ТС, люди занимаются фигнёй вместо главного... K>А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором. Сразу все вспомнят как деды проектировали системы, про бинарные протоколы, про CORBA, и про другие технологии переосмыслив их в текущих реалиях лишь бы уменьшить нагрузку на железо, трафик и управление системами. Это же надо, люди когда-то боролись с оверхедом IP заголовков придумав ROHC но всё про##&*@ тупо добавив текст во всех протоколах выше транспорта.
RoHC есть там где я сейчас, но там транспорт голоса/видео занимает заметную часть.
А как пример бинарного протокола с массой оптимизаций это QUIC, который скоро дойдёт, наверно, до 50% мирового трафика.
А "чем заниматься" — ну упоминалось же про 20MB скриптов? Их тоже загрузить надо (не знаю, что там с кэшированием в браузере, но явно тоже работает не всегда).
Здравствуйте, Andir, Вы писали:
S>>Э-э?.. Только что проверил, чуть меньше шести метров. Просто google.com/maps, гугл-эккаунта у меня нет, масштаб всей Земли. A>Это ж про google maps образца 2006 года. Возможно это даже про тогдашнюю мобильную версию речь.
A>
The performance of websites and the impact that has, has been well documented over the years. In 2007 Amazon reported that for every 100 ms increase in load time of Amazon.com their sales decreased by 1%. Google also reported similar results in 2006 with their Google Maps product. Google found that by reducing the size of the page from 100KB to 80KB, their traffic shot up by 10% in the first week and then 25% in the following three weeks.
Здравствуйте, vsb, Вы писали:
vsb>У меня ничего не тормозит. Не знаю, что там за мудрецы.
просто хорошее соединение с интернет.
я недавно в Калифорнии с ооочень слабой и не стабильной мобильной связью пытался открыть сайт AT&T, что бы как раз интернет провести... я все проклял сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так я же туда иду, потому что у меня нет интернета и хочу его провести мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура )
Здравствуйте, baxton_ulf, Вы писали:
_>просто хорошее соединение с интернет.
А у кого оно сейчас плохое?
_>я недавно в Калифорнии с ооочень слабой и не стабильной мобильной связью пытался открыть сайт AT&T, что бы как раз интернет провести... я все проклял сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так я же туда иду, потому что у меня нет интернета и хочу его провести мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура )
Ну не знаю, что там в Калифорнии. У меня в деревне дом, там 4G даёт 10-50 мегабитов. И пинг вполне пристойный. Думаю, у большинства людей так. Оптимизируют под большинство.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, baxton_ulf, Вы писали:
_>>просто хорошее соединение с интернет.
vsb>А у кого оно сейчас плохое?
есть блайнд-споты, в одном из таких я и оказался
_>>я недавно в Калифорнии с ооочень слабой и не стабильной мобильной связью пытался открыть сайт AT&T, что бы как раз интернет провести... я все проклял сайт настолько перегружен всякой х*йней, что зависает намертво. вообще ничего не грузится. ну нельзя же так я же туда иду, потому что у меня нет интернета и хочу его провести мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура )
vsb>... Оптимизируют под большинство.
о, это теперь называют "оптимизируют", как я отстал от жизни
Здравствуйте, L.K., Вы писали:
LK>А насчёт JSON->Messagepack я вообще не понял смысла. Что мешало тот же самый JSON хранить сжатым gzip-ом? LK> А при передаче по сети JSON сожмётся веб-сервером.
Ты статью то читал? Они ж попробовали, получили 10% уменьшения, "продуктовый эффект незначительный".
Здравствуйте, Shtole, Вы писали:
S>Просто вы хорошо думаете о людях. Вы думаете, это олимпиадники, не набравшиеся мудрости. А я думаю, они достаточно мудры, чтобы за свою деструктивную деятельность получать очень хорошие деньги
Это так не работает. Нет, тут именно хороший технический бэкграунд и очень плохое взаимодействие с продактами. Чего то там наоптимизировали, получили отличные циферки, подстелили вумные исследования про латентность, а вот про продукт свой забыли.
Здравствуйте, netch80, Вы писали:
N>3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво.
Серьезно? Тогда можно смело в помоечку.
N>Я парсил SIP (идентичен по стилю и почти по деталям), это не укладывается в привычные LL/LR, по факту это нерекурсивный PEG на классах символов. Кодеры бы такое не придумали.
Это смотря какие кодеры. Те которые знают про LL/LR — возможно, хотя при ручном раскладывании не особо сложно в особо тонких местах разруливать конфликты рукопашным кодом. А вот те которые не знают — легко выдадут что угодно отплясывания от рукопашного жопорукого кода парсера (т.е. грамматика вообще не проектируется, просто пишется сразу код).
Здравствуйте, Kernan, Вы писали:
K>А чем они должны заниматься? Мне вот кажется мы скоро начнём входить на новый виток оптимизации бесконечных джейсонов и текста чтобы не грузить сервера лишним трафиком и разбором
Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику. Основная паства бинарных протоколов это всякая дохлая мелочь типа клиентов IoT, где даже 3 копейки — деньги.
K>про CORBA
Шо, опять OORPC? Нафига? Еще недостаточно шишек набито граблями?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это тебе в теории так кажется. А на практике особой разницы между JSON+gzip и каким нибудь MessagePack нет ни по памяти, ни по цпу, ни по трафику.
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Я парсил SIP (идентичен по стилю и почти по деталям), это не укладывается в привычные LL/LR, по факту это нерекурсивный PEG на классах символов. Кодеры бы такое не придумали. НС>Это смотря какие кодеры. Те которые знают про LL/LR — возможно, хотя при ручном раскладывании не особо сложно в особо тонких местах разруливать конфликты рукопашным кодом. А вот те которые не знают — легко выдадут что угодно отплясывания от рукопашного жопорукого кода парсера (т.е. грамматика вообще не проектируется, просто пишется сразу код).
То есть разбирать такое ты не пробовал. Иначе бы не выдавал комментарии, как тот программист летящим на воздушном шаре.
N>>3. Оно зависит от идентичности определений схемы на обеих сторонах (ну и от наличия самой схемы). Версионность не работает, или работает криво. НС>Серьезно? Тогда можно смело в помоечку.
Кажется, пора формулировать принцип "послушай НС и сделай строго ортогонально тому, что он предлагает".
Здравствуйте, 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>Версионность отдана на прикладной уровень.
Если у тебя нижний уровень неверсионный, никакой прикладной ситуацию не исправит, максимум набор костылей будет. Вот наоборот, сломать версионность на прикладном уровне — это запросто.
Здравствуйте, 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 — тоже то ещё пожиралово серверных ресурсов.
Потом ресурсы идут на хрен пойми что. Но я не до конца дочитал.
я же туда иду, потому что у меня нет интернета и хочу его провести 
мне нахер не нужны все эти их рюшки (я специально пробовал открывать RSDN — все грузилось на ура 
)
