Вы понимаете, что все участвующие в сравнении библиотек предназначены для преобразования в формат отличный от byte[]? Грубо преобразует Object в строку, которая далее будет преобразована в массив байт при передаче в распределенной системе! Т.е. выполняется преобразование Object -> JSON -> byte[]. Это всегда будет работать хуже, чем прямое преобразование Object в byte[]. ВСЕГДА!
Если Вы получили другой результат, то Вам нужно проверить правильность тестирования.
Это лукавство — ваша цитата понятия сериализации. В распределенной системе (указано в вашей преамбуле) понятие сериализации одно — преобразование программного объекта в поток (массив байт).
В этом преобразовании Java Standart всегда будет работать быстрее любой другой рассмотренной вами в сравнении технологии, ввиду отсутствия других преобразований. Object -> byte[] всегда быстрее по сравнению с Object -> JSON -> byte[].
Тогда мы говорим о совершенно разных понятиях "сериализации" и "десериализации". В моем понимании эти понятия связаны с выводом в поток и восстановлением объекта из потока.
Что намерили Вы и чем помогли вам результаты ваших измерений — не понимаю. Все же преамбуле к статье Вы написали "передача состояния в распределенной среде", а в результатах измерений распределенной среды получается у Вас нет.
И получается, что мой результат 0 мс на приемной стороне (удаленном узле) ничем не хуже вашего.
Во-вторых, если вы взглянете на первые графики из раздела «Гонки», то увидите, что для Java Standard цикл сериализации/десериализации данных размером порядка 1 КБ (примерно ваш размер) у нас занял 0,007 + 0,021 = 0,028 мс. У вас же получилось 4 мс за 2 цикла сериализации/десериализации + сетевые задержки. Это, без учёта сети, в 2000/28=~71 раз медленнее нашего результата. И где здесь «плачевный» результат?..
Вы не путаете результат своего измерения с секундами? Системные часы точнее миллисекунд измерять не позволяют!
Измерять можно по разному и ссылка на использование софта еще ни о чем не говорит. Разные люди, при использовании одного и того инструмента, могут получить разный результат. Доказано практикой.
Я Вам привел цифры ведь тоже не с потолка, а результат сбора статистики. И этот результат кардинально отличается от ваших измерений. Многократность большого значения не имеет, а лишь позволяет "подавить" различные погрешности измерений, вносимых синхронизаций часов и не равномерной загрузкой используемых внешних ресурсов (сети например).
Мои измерения строятся на фиксации временных точек непосредственно перед вызовом удаленного метода и сразу после получения результата этого вызова. Внутри вызова "спрятан" код "упаковки" объектов в поток. Какие либо другие преобразования данных отсутствуют.
В вашем случае, из-за обилия рассмотренных решений, думаю, внутренний код вызовов в каждом из них кардинально отличаются. Соответственно, большую погрешность измерений будет вносит эти существенные отличия.
Но мне интересно, где Вы умудрились потерять столько времени на использовании "Java Standart" в своих измерениях. Различия в JVM IBM и SUN (Oracle) я отвергаю. Я работал и с тем и другим, в них есть различия, но другого рода.
Поясните, что измерялось в вашем случае использования "Java Standart". Как реализован вызов? Сериализованы ли объекты передаваемые через сеть?
Взял статистику по одну из запросов — минимальное время 1 мс, максимальное время — 1005 мс, среднее время — 4 мс, счетчик запросов — 71 тыс. Это время замера — отправки запроса на удаленный узел (сериализация запроса — сеть — десериализация запроса — обработка — сериализация ответа — сеть — десериализация ответа)
Не понимаю, как Вы умудрились намерить для Java Standart такой "плачевный" результат.
У меня есть постоянные "измерители" полного цикла запроса и ответа на локальном и на удаленном узлах. На удаленном узле десериализация запроса, обработка запроса, сериализация ответа суммарно всегда отрабатывает менее 1 мс. На запрашиваемом узле сериализация запроса, ожидание, десериализация ответа суммарно менее 5 мс. Используется стандартная Java сериализация (из коробки). Используется ZIP для сжатия данных при передаче по сети по протоколу HTTP. По протоколу RMI результат будет еще ниже (не будет передачи надстройки HTTP протокола над передаваемыми данными по сети).
Объем переданных данных у меня не отслеживается (по косвенным признакам менее 1к в сжатом виде). Используется OpenJDK 1.8.
Чем меньше выполняется различных преобразований при сериализации — десериализации, тем лучше должен быть результат по определению. Java Standart — делает подобное, на мой взгляд, с наименьшими преобразованиями данных по сравнению со всем остальным перечисленным вами. Поэтому, думаю, что у Вас есть погрешность измерений для Java Standart.
REST просто пример, не более. Повторюсь, какие запросы обрабатывать не имеет значения.
"В одноузловой системе с элементарными функциями" производительность целиком и полностью зависит от мощности этого узла. Терять производительность практически негде.
Avalanche — не заказная разработка! Эта результат моей личной инициативы. В предшественнике реализация устойчивости работы в распределенной среде получилась очень громоздкой, из-за чего пришлось отказаться от ее расширения при возникновении одного нового нетипичного требования (потребовалась внутренняя сервисная функция сервера приложений). Стало лень вносить изменения в существующею реализацию ради этой функции. Но задуматься это требование заставило, что надо это все как то упростить. Плюс опыт эксплуатации распределенной среды поднакопился. В результате и появился продукт — Avalanche.
Avalanche — сказка! :-) Создавать распределенные системы или программные кластеры не просто просто, а очень просто. Появилась возможность создавать виртуальный сервер приложений на основе множества узлов в распределенной среде.
А REST запросы это или что то другое — значение не имеет. Любой "простой" запрос может потребовать большого объема вычислений для получения "простого" ответа. Я знаю одно, чем меньше выполняется в коде различных преобразований тем более производительная система. Поэтому считаю некоторые очень распространенные и популярные продукты "программным мусором". Этот пример демонстрация такого подхода. Можно из этого примера исключить Avalanche? Можно, только кода будет чуть больше и "распределенность" пропадет. Этот пример с легкостью будет работать с двумя, тремя и т.д. копиями БД. Поменяли конфигурацию, получили резервирование БД — все. Если этот пример немного усложнить, то можно получить отказоустойчивую систему из двух узлов и двух копий БД.
Да, про 16К описывал, это была моя личная авантюра без какого либо согласования и моей полной уверенности отсутствия каких либо серьезных последствий. Цель эксперимента — проверка устойчивости работы сервера приложений с БД, БД "убивать" нельзя вне зависимости от действий пользователей.
Упал один узел сервера приложения, на этапе обработки полученных результатов. "Транспорт" (распределенная система) выдержал. Для Avalanche пока не нашел варианта внедрения с подобными нагрузками.
Согласитесь, что нельзя сравнивать по количеству запросов разные системы.
Запрос запросу рознь! Не во всех системах можно провести нагрузочное тестирование или смоделировать его. Чтобы построить испытательный полигон моей системы для проведения предложенных вами тестов нужны миллиарды рублей (порядок цифр реальный, не сомневайтесь) и уйму времени и специалистов. На промышленной системе подобные тесты проводить никогда не разрешат.
Для небольших систем, наподобие той, что описана в статье по вашей ссылке, построить тестовый полигон его "вкивь и вкось" не проблема.
В статье, при беглом ознакомлении, описывается проблема производительности одноузловой системы с элементарными, на мой взгляд, функциями.
Если сложить все процессорные операции для обслуживания всего лишь одного запроса в моей системе — не сомневаюсь, миллиард будет с легкостью превзойден.
Что Вы понимаете под одним запросом? Одну отдельную операцию? Вставка или чтение одной записи?
Я понимаю под одним запросом пользователя — запрос "полезной" для него информации, который формируется на множестве записей из множества БД множеством серверов приложений.
Avalanche, как и предшественник — это промежуточное программное обеспечение, которое можно встраивать в любую предметную область. Сервер приложений "накручивается" сверху него. Промышленную систему, которая сейчас находится в эксплуатации — тестировали, "одномоментно" было послано около 16 000 запросов на сервер приложений, этот узел упал, когда начал раздавать результаты по OutOfMemory. Все остальное осталось в рабочем состоянии.
Тест тесту рознь. Avalanche — продукт, который предоставляет готовый сервис для создания распределенных отказоустойчивых систем непрерывной доступности. Внутренние функционал Avalanche не создает какой либо существенной нагрузки. Нагрузка вся "от предметной области". Тесты на устойчивость Avalanche естественно проводились, но это не нагрузочное тестирование — нагружать нечего.
Для эксперимента поменял зависимость
на
Все осталось в рабочем состоянии, корректировать код не потребовалось
Заглянул во внутрь файла jakarta.servlet-api-4.0.3.jar, отличий не увидел. Имена пакетов не изменяются.
Главное, чтобы в названия пакетов и классов не изменялись. А имена библиотек дело десятое.
:-) Хорошо. У каждого свое мнение.
Но ваши выводы сомнительны.
Вы понимаете, что все участвующие в сравнении библиотек предназначены для преобразования в формат отличный от byte[]? Грубо преобразует Object в строку, которая далее будет преобразована в массив байт при передаче в распределенной системе! Т.е. выполняется преобразование Object -> JSON -> byte[]. Это всегда будет работать хуже, чем прямое преобразование Object в byte[]. ВСЕГДА!
Если Вы получили другой результат, то Вам нужно проверить правильность тестирования.
Что понимаете под Object? Java-object c полями объекта, JSON (String) или что то другое?
Это лукавство — ваша цитата понятия сериализации. В распределенной системе (указано в вашей преамбуле) понятие сериализации одно — преобразование программного объекта в поток (массив байт).
В этом преобразовании Java Standart всегда будет работать быстрее любой другой рассмотренной вами в сравнении технологии, ввиду отсутствия других преобразований. Object -> byte[] всегда быстрее по сравнению с Object -> JSON -> byte[].
Тогда мы говорим о совершенно разных понятиях "сериализации" и "десериализации". В моем понимании эти понятия связаны с выводом в поток и восстановлением объекта из потока.
Что намерили Вы и чем помогли вам результаты ваших измерений — не понимаю. Все же преамбуле к статье Вы написали "передача состояния в распределенной среде", а в результатах измерений распределенной среды получается у Вас нет.
И получается, что мой результат 0 мс на приемной стороне (удаленном узле) ничем не хуже вашего.
Вы не путаете результат своего измерения с секундами? Системные часы точнее миллисекунд измерять не позволяют!
Измерять можно по разному и ссылка на использование софта еще ни о чем не говорит. Разные люди, при использовании одного и того инструмента, могут получить разный результат. Доказано практикой.
Я Вам привел цифры ведь тоже не с потолка, а результат сбора статистики. И этот результат кардинально отличается от ваших измерений. Многократность большого значения не имеет, а лишь позволяет "подавить" различные погрешности измерений, вносимых синхронизаций часов и не равномерной загрузкой используемых внешних ресурсов (сети например).
Мои измерения строятся на фиксации временных точек непосредственно перед вызовом удаленного метода и сразу после получения результата этого вызова. Внутри вызова "спрятан" код "упаковки" объектов в поток. Какие либо другие преобразования данных отсутствуют.
В вашем случае, из-за обилия рассмотренных решений, думаю, внутренний код вызовов в каждом из них кардинально отличаются. Соответственно, большую погрешность измерений будет вносит эти существенные отличия.
Но мне интересно, где Вы умудрились потерять столько времени на использовании "Java Standart" в своих измерениях. Различия в JVM IBM и SUN (Oracle) я отвергаю. Я работал и с тем и другим, в них есть различия, но другого рода.
Поясните, что измерялось в вашем случае использования "Java Standart". Как реализован вызов? Сериализованы ли объекты передаваемые через сеть?
Взял статистику по одну из запросов — минимальное время 1 мс, максимальное время — 1005 мс, среднее время — 4 мс, счетчик запросов — 71 тыс. Это время замера — отправки запроса на удаленный узел (сериализация запроса — сеть — десериализация запроса — обработка — сериализация ответа — сеть — десериализация ответа)
Не понимаю, как Вы умудрились намерить для Java Standart такой "плачевный" результат.
У меня есть постоянные "измерители" полного цикла запроса и ответа на локальном и на удаленном узлах. На удаленном узле десериализация запроса, обработка запроса, сериализация ответа суммарно всегда отрабатывает менее 1 мс. На запрашиваемом узле сериализация запроса, ожидание, десериализация ответа суммарно менее 5 мс. Используется стандартная Java сериализация (из коробки). Используется ZIP для сжатия данных при передаче по сети по протоколу HTTP. По протоколу RMI результат будет еще ниже (не будет передачи надстройки HTTP протокола над передаваемыми данными по сети).
Объем переданных данных у меня не отслеживается (по косвенным признакам менее 1к в сжатом виде). Используется OpenJDK 1.8.
Чем меньше выполняется различных преобразований при сериализации — десериализации, тем лучше должен быть результат по определению. Java Standart — делает подобное, на мой взгляд, с наименьшими преобразованиями данных по сравнению со всем остальным перечисленным вами. Поэтому, думаю, что у Вас есть погрешность измерений для Java Standart.
REST просто пример, не более. Повторюсь, какие запросы обрабатывать не имеет значения.
"В одноузловой системе с элементарными функциями" производительность целиком и полностью зависит от мощности этого узла. Терять производительность практически негде.
Avalanche — не заказная разработка! Эта результат моей личной инициативы. В предшественнике реализация устойчивости работы в распределенной среде получилась очень громоздкой, из-за чего пришлось отказаться от ее расширения при возникновении одного нового нетипичного требования (потребовалась внутренняя сервисная функция сервера приложений). Стало лень вносить изменения в существующею реализацию ради этой функции. Но задуматься это требование заставило, что надо это все как то упростить. Плюс опыт эксплуатации распределенной среды поднакопился. В результате и появился продукт — Avalanche.
Avalanche — сказка! :-) Создавать распределенные системы или программные кластеры не просто просто, а очень просто. Появилась возможность создавать виртуальный сервер приложений на основе множества узлов в распределенной среде.
А REST запросы это или что то другое — значение не имеет. Любой "простой" запрос может потребовать большого объема вычислений для получения "простого" ответа. Я знаю одно, чем меньше выполняется в коде различных преобразований тем более производительная система. Поэтому считаю некоторые очень распространенные и популярные продукты "программным мусором". Этот пример демонстрация такого подхода. Можно из этого примера исключить Avalanche? Можно, только кода будет чуть больше и "распределенность" пропадет. Этот пример с легкостью будет работать с двумя, тремя и т.д. копиями БД. Поменяли конфигурацию, получили резервирование БД — все. Если этот пример немного усложнить, то можно получить отказоустойчивую систему из двух узлов и двух копий БД.
Да, про 16К описывал, это была моя личная авантюра без какого либо согласования и моей полной уверенности отсутствия каких либо серьезных последствий. Цель эксперимента — проверка устойчивости работы сервера приложений с БД, БД "убивать" нельзя вне зависимости от действий пользователей.
Упал один узел сервера приложения, на этапе обработки полученных результатов. "Транспорт" (распределенная система) выдержал. Для Avalanche пока не нашел варианта внедрения с подобными нагрузками.
Согласитесь, что нельзя сравнивать по количеству запросов разные системы.
Запрос запросу рознь! Не во всех системах можно провести нагрузочное тестирование или смоделировать его. Чтобы построить испытательный полигон моей системы для проведения предложенных вами тестов нужны миллиарды рублей (порядок цифр реальный, не сомневайтесь) и уйму времени и специалистов. На промышленной системе подобные тесты проводить никогда не разрешат.
Для небольших систем, наподобие той, что описана в статье по вашей ссылке, построить тестовый полигон его "вкивь и вкось" не проблема.
В статье, при беглом ознакомлении, описывается проблема производительности одноузловой системы с элементарными, на мой взгляд, функциями.
Если сложить все процессорные операции для обслуживания всего лишь одного запроса в моей системе — не сомневаюсь, миллиард будет с легкостью превзойден.
У нас разные понятия об "одном запросе"!
Что Вы понимаете под одним запросом? Одну отдельную операцию? Вставка или чтение одной записи?
Я понимаю под одним запросом пользователя — запрос "полезной" для него информации, который формируется на множестве записей из множества БД множеством серверов приложений.
Avalanche, как и предшественник — это промежуточное программное обеспечение, которое можно встраивать в любую предметную область. Сервер приложений "накручивается" сверху него. Промышленную систему, которая сейчас находится в эксплуатации — тестировали, "одномоментно" было послано около 16 000 запросов на сервер приложений, этот узел упал, когда начал раздавать результаты по OutOfMemory. Все остальное осталось в рабочем состоянии.
Тест тесту рознь. Avalanche — продукт, который предоставляет готовый сервис для создания распределенных отказоустойчивых систем непрерывной доступности. Внутренние функционал Avalanche не создает какой либо существенной нагрузки. Нагрузка вся "от предметной области". Тесты на устойчивость Avalanche естественно проводились, но это не нагрузочное тестирование — нагружать нечего.
Отличная новость, вашу душа теперь будет спокойна.
На Вас не угодишь, это не годится, и другое плохо.
Решайте вашу проблему самостоятельно.