13 651
правка
Изменения
Новая страница: «На хайлоад в этом году не ходил, но услышал от коллеги про доклад … про вот этот вот докла…»
На хайлоад в этом году не ходил, но услышал от коллеги про доклад … про вот этот вот доклад (на хайлоаде был он же):
https://2019.jokerconf.com/2019/talks/4wj9og0tij3wpxe3ourovr/
Вкратце: выходит дядька и говорит, что вот, в типичной веб-архитектуре с БД, memcached и stateless приложением очень большие затраты на маршалинг и демаршалинг [дядя реальный олд, раз сериализация у него маршалинг — но на это забьём]. Конкретно, до 85 % времени на это дело якобы уходит.
Поэтому они взяли Кассандру, засунули её прямо в Java процесс с приложением, и общаются с ней локально. Типа она распределённая, поэтому всё остаётся отказоустойчиво — она синхронизируется с другими нодами. И типа поэтому всё хорошо.
И вот с чего я тут охреневаю — это с 85 % затрат на сериализацию. Ну треш же какой-то! Ладно, ява, ну и что — https://github.com/fabienrenaud/java-json-benchmark - вот бенч разных библиотек JSON для явы. Самая быстрая даёт ~800 тысяч разборов и ~1.5 млн кодирований по 1 КБ в секунду, да и банальный Jackson не сильно отстаёт: ~500к / ~1 м.
Оказывается, 85 % это ссылка на статью: https://research.google/pubs/pub48030/. Статья тоже кривая. Не объясняя, ЧТО они тестировали, они действительно приводят цифры в оверхед сериализации в 45 % CPU и 85 % передачи лишних данных по сети и на основании этого агитируют за написание stateful бэкенда.
Если присмотреться внимательнее, там, правда, есть пометка:
<blockquote>
Finally, our experiments in Section 3 show that if only part of the record is needed (10 %), RInK stores incur both extra CPU (46 %) and network (85 %) costs
</blockquote>
<blockquote>
For example, consider anapplication that caches the address books for all online usersin aRInKstore: for each user, the address book is stored as asingle key-value pair. If a request arrives from Alice to readBob’s phone number from her address book, all of Alice’scontacts must be fetched and unmarshalled, even thoughonly a small portion of the data is needed.
</blockquote>
Б**дь! Ну так не надо так писать, чтобы для чтения 1 номера телефона приложение читало всю адресную книгу!!!
А к дядьке этому у меня один вопрос — он сам вообще что-то сравнивал? Или как всегда — «потому что можем»?
Каждый раз немного удивляюсь от их микросервисо-джабба-страданий… они же ими балуются ещё с тех пор, когда их не называли микросервисами. И в страданиях изобретали сначала собственный java-сериализатор, потом собственный кэш, сначала борясь с gc, а потом забив и уйдя куда-то на разделяемую память. Вылысыпыдысты.
Ну ладно. «Ночью через лес», когда файловое хранилище на postgresql изобретал, тоже сначала бодрый был.
{{wl-publish: 2020-01-14 23:37:40 +0300 | VitaliyFilippov }}
https://2019.jokerconf.com/2019/talks/4wj9og0tij3wpxe3ourovr/
Вкратце: выходит дядька и говорит, что вот, в типичной веб-архитектуре с БД, memcached и stateless приложением очень большие затраты на маршалинг и демаршалинг [дядя реальный олд, раз сериализация у него маршалинг — но на это забьём]. Конкретно, до 85 % времени на это дело якобы уходит.
Поэтому они взяли Кассандру, засунули её прямо в Java процесс с приложением, и общаются с ней локально. Типа она распределённая, поэтому всё остаётся отказоустойчиво — она синхронизируется с другими нодами. И типа поэтому всё хорошо.
И вот с чего я тут охреневаю — это с 85 % затрат на сериализацию. Ну треш же какой-то! Ладно, ява, ну и что — https://github.com/fabienrenaud/java-json-benchmark - вот бенч разных библиотек JSON для явы. Самая быстрая даёт ~800 тысяч разборов и ~1.5 млн кодирований по 1 КБ в секунду, да и банальный Jackson не сильно отстаёт: ~500к / ~1 м.
Оказывается, 85 % это ссылка на статью: https://research.google/pubs/pub48030/. Статья тоже кривая. Не объясняя, ЧТО они тестировали, они действительно приводят цифры в оверхед сериализации в 45 % CPU и 85 % передачи лишних данных по сети и на основании этого агитируют за написание stateful бэкенда.
Если присмотреться внимательнее, там, правда, есть пометка:
<blockquote>
Finally, our experiments in Section 3 show that if only part of the record is needed (10 %), RInK stores incur both extra CPU (46 %) and network (85 %) costs
</blockquote>
<blockquote>
For example, consider anapplication that caches the address books for all online usersin aRInKstore: for each user, the address book is stored as asingle key-value pair. If a request arrives from Alice to readBob’s phone number from her address book, all of Alice’scontacts must be fetched and unmarshalled, even thoughonly a small portion of the data is needed.
</blockquote>
Б**дь! Ну так не надо так писать, чтобы для чтения 1 номера телефона приложение читало всю адресную книгу!!!
А к дядьке этому у меня один вопрос — он сам вообще что-то сравнивал? Или как всегда — «потому что можем»?
Каждый раз немного удивляюсь от их микросервисо-джабба-страданий… они же ими балуются ещё с тех пор, когда их не называли микросервисами. И в страданиях изобретали сначала собственный java-сериализатор, потом собственный кэш, сначала борясь с gc, а потом забив и уйдя куда-то на разделяемую память. Вылысыпыдысты.
Ну ладно. «Ночью через лес», когда файловое хранилище на postgresql изобретал, тоже сначала бодрый был.
{{wl-publish: 2020-01-14 23:37:40 +0300 | VitaliyFilippov }}
