на главнуюВсе эхи SU.SOFTW
войти ?

Go, etcd, protobuf

От Sergey Poziturin (2:5020/2141.3) к Gennadij Pastuhov

В ответ на Заголовок предыдущего сообщения в треде (Имя Автора)


Hello, Gennadij Pastuhov.
On 17.11.17 11:04 ДП you wrote:

AS>>>> json ещё понятнее для разработчика, достаточно поставить
AS>>>> простенькую проксю, чтобы смотреть что пришло, что ушло.
GP>>> Это нужно только для отладки.
SP>> Это кроме всего прочего ещё и отраслевой стандарт. Это значит,
SP>> что на нем можно делать интеграцию со всеми.
GP> А для связи внутри своих сервисов?

Я использую.

AS>>>> Плюс всякие rest-ы удобнее описывать на нём.
GP>>> С невысокими нагрузками.
SP>> И с высокими тоже.
GP> Есть какие-то тесты нагрузок?

Сравнительных нет, абсолютные есть. Всегда слабое звено в этих тестах не парсинг json, а бизнес-логика или работа с хранилищем данных. Но это у меня так.

AS>>>> Но сериализация в строки как правило медленее, чем бинарная
AS>>>> сериализация.
GP>>> Вот именно.
SP>> Каков проигрыш по времени и где слабое звено?
GP> Да, интересно посмотреть.

Ждём комментариев.

SP>> Если процессор, то мне это не очень актуально, а что ещё может
SP>> быть?
GP> Как может быть неактуален процессор?

У меня микросервисы, так что если я увижу, что где-то упираюсь в cpu, рядом просто стартует ещё один инстанс. Для меня и моих клиентов это дешевле, чем внедрять другой сериалайзер с неочевидной выгодой по скорости. :)

Вот если бы на тесты глянуть, тут уже да. Можно было бы подумать. Но опять же, повторю, пока ещё не упирался в передачу сообщений между сервисами.

--
Best regards!
Posted using Hotdoged on Android
--- Hotdoged/2.13.5/Android
* Origin: Android device, Milky Way (2:5020/2141.3)

Ответы на это письмо:

From: Username
Заголовок следующего сообщения в треде может быть длинным и его придется перенести на новую строку

From: Username
Или коротким

FGHI-url этого письма: area://SU.SOFTW?msgid=2:5020/2141.3+b086517e