Немного режет глаза отсутствие static в константе и сравнение equals не «от константы», но в целом хорошо. Побольше бы ещё про многоуровневую сортировку, reduce, сложный коллектор для мапы с возможностью указать тип используемой реализации и стратегию разрешения конфликтов, в случае совпадения ключей.
Вычисление UUID затратная операция, влияющая на скорость работы. Но, в целом, если у нас хайлоад, то можно пойти дальше и оперировать строками (если про Spring MVC речь) без десериализации Jackson-ом, закинуть в фоновый процесс и там уже пускай обрабатывается.
@dmitriizolotov подскажите, какими инструментами пользуетесь для тестирования API работающих на механизме подписок и мультиплексирования? Например, чтобы проверить максимальную пропускную способность RSocket channel соединения.
Ещё стоит оптимизировать приложения по области их деятельности:
Должно выживать под большой нагрузкой => поднимаем фоновый процесс + пулинг модель, убираем сериализацию, переходим на Webflux (если есть возможность), включаем http/2 и.т.д.
Должно обрабатывать большие массивы данных => вспоминаем про спец. инструменты хранилищ данных, буфферные чтения, воскрешаем SAX парсеры и п.р.
По поводу теста целиком - указано в дисклеймере. Зачем нужно среднее арифметическое? Предположим, часть вызовов потом закешируют на рефакторинге, например. Тогда нужно гонять логику несколько раз, чтобы не попасть в кеш (фиче тогл, например, забыли прикрутить на отключение кеша). Плюс надо также учитывать факторы холодного старта и прочее. Конечно, можно попросить организовать Нагрузочное тестирование, но на каждый чих его делать затратно, а если проблем перфоманса вагонетка, то желательно их постепенно тестировать до Нагрузочного. Можно, конечно, попросить QA погонять рест десяток раз, но не лучше ли автоматизировать это тестом? Можно и юнит тестом, но это не так рационально, когда для этого есть соответствующие инструменты.
Про юнит тесты согласен, но вычислять среднее арифметическое времени вызовов - там нужно думать как это делать, чтобы не собрать велик)
По поводу нагрузочного тестирования - безусловно его нужно проводить, но на практике его проводят только в случае мажорных релизов или в экстренных ситуациях, после решения таких вот проблем, чтобы проверить фиксы разработчиков.
Вообще, блокирующие тесты могут больно стрелять в случае, когда все коннекты Нетти будут заблокированы или же 2 реактивных стрима будут использовать один коннект, да и реактор с 3 версии настоятельно не рекомендует использовать block методы. Поэтому для тестирования функционала лучше использовать зависимость reactor-test. Таким макаром можно не только не блокирующие тесты писать, но и тестить события подписки и т.д.
Подскажите, сработает ли проверка на классы из сторонних зависимостей, подключаемых мавеном, например, которые могут возвращать null?
Немного режет глаза отсутствие static в константе и сравнение equals не «от константы», но в целом хорошо. Побольше бы ещё про многоуровневую сортировку, reduce, сложный коллектор для мапы с возможностью указать тип используемой реализации и стратегию разрешения конфликтов, в случае совпадения ключей.
Не совсем понятно, чем Clock лучше проставления ZoneOffset/ZoneId ?
Имхо, проще тогда на аэростаты вешать, что по-моему ребята из Google уже обкатывали в странах Африки.
Вычисление UUID затратная операция, влияющая на скорость работы. Но, в целом, если у нас хайлоад, то можно пойти дальше и оперировать строками (если про Spring MVC речь) без десериализации Jackson-ом, закинуть в фоновый процесс и там уже пускай обрабатывается.
Понял, спасибо.
@dmitriizolotov подскажите, какими инструментами пользуетесь для тестирования API работающих на механизме подписок и мультиплексирования? Например, чтобы проверить максимальную пропускную способность RSocket channel соединения.
Ещё стоит оптимизировать приложения по области их деятельности:
Должно выживать под большой нагрузкой => поднимаем фоновый процесс + пулинг модель, убираем сериализацию, переходим на Webflux (если есть возможность), включаем http/2 и.т.д.
Должно обрабатывать большие массивы данных => вспоминаем про спец. инструменты хранилищ данных, буфферные чтения, воскрешаем SAX парсеры и п.р.
Верно, лучше строкой. Здесь использование UUID - малая часть того, что нужно рефакторить, но статья не про рефакторинг, а про его тестирование.
По поводу теста целиком - указано в дисклеймере. Зачем нужно среднее арифметическое? Предположим, часть вызовов потом закешируют на рефакторинге, например. Тогда нужно гонять логику несколько раз, чтобы не попасть в кеш (фиче тогл, например, забыли прикрутить на отключение кеша). Плюс надо также учитывать факторы холодного старта и прочее. Конечно, можно попросить организовать Нагрузочное тестирование, но на каждый чих его делать затратно, а если проблем перфоманса вагонетка, то желательно их постепенно тестировать до Нагрузочного. Можно, конечно, попросить QA погонять рест десяток раз, но не лучше ли автоматизировать это тестом? Можно и юнит тестом, но это не так рационально, когда для этого есть соответствующие инструменты.
Про юнит тесты согласен, но вычислять среднее арифметическое времени вызовов - там нужно думать как это делать, чтобы не собрать велик)
По поводу нагрузочного тестирования - безусловно его нужно проводить, но на практике его проводят только в случае мажорных релизов или в экстренных ситуациях, после решения таких вот проблем, чтобы проверить фиксы разработчиков.
Вообще, блокирующие тесты могут больно стрелять в случае, когда все коннекты Нетти будут заблокированы или же 2 реактивных стрима будут использовать один коннект, да и реактор с 3 версии настоятельно не рекомендует использовать block методы. Поэтому для тестирования функционала лучше использовать зависимость reactor-test. Таким макаром можно не только не блокирующие тесты писать, но и тестить события подписки и т.д.