Вы наверняка уже поняли, что удалять биты из фильтра нельзя, так как один и тот же бит может быть занят несколькими элементами. Как нам тогда представлять удалённые элементы, используя такой фильтр?
Представить второй фильтр удаленных элементов и проверять вхождение перед основным. Но, как минимум, вероятностная структура для этого не подходит - достаточно примитивного Set
Чем текущее решение лучше/практичнее Spring Data REST? Зачем выдумывать очередной велосипед, кроме как получение физического контроля над выполняемой логикой?
Западные техники мониторинга команд в т.ч. скрам - не применимы к продуктовым компаниям РФ, пока существуют фундаментальные проблемы процессов. Это все только создает для рабочей среды огромную трату времени..
Тест с reactor в корне неверный. Обратитесь к документации, где четко сказано, что любое IO необходимо публиковать на выделенный Schedulers. Иначе, что вы хотите сказать графиками - reactor хуже servlet stack?
Тестирование различных пулов Reactor стоит оставить для статей по реактору.
Если тестировать - то правильно. Как минимум по графикам уже понятно, чем event loop занят 99% времени.
Интересно, что же все таки случится в «правильном тесте» webflux, если добавить к вызову репозитория switch context скажем bounded elastic пул. В MVC - где тесты с тем же CompletableFuture, а как же loom вместо стандартной фабрики потока на запрос?
Описание пайплайна не верное, тест можно считать провальным.
ну давайте теперь будем вообще делать один класс для всех сущностей и репозиториев, че мелочится то
и среднее время ответа увеличивается на те самые 2-3 итерации, в бизнес сценариях бесполезно, когда необходимо получать ответ почти сразу
так, стоп.. с чего резко такая уверенность, что 1 и тот же запрос на разном сетевом стеке должен выполнятся быстрее или медленнее? 0_о
Кажется должно также решаться буферным движком перед вставкой в ReplacingMergeTree
Красный флаг.. да откуда вы все такие вылезли
главный вопрос - зачем?
Лови душнилу (:
Представить второй фильтр удаленных элементов и проверять вхождение перед основным. Но, как минимум, вероятностная структура для этого не подходит - достаточно примитивного Set
А как обыграете ситуацию с RefreshScope?
А про что тогда 0_о? В данный момент вы делаете тоже самое что и указанный модуль. Поясните в чем же фундаментальные различия.
Чем текущее решение лучше/практичнее Spring Data REST?
Зачем выдумывать очередной велосипед, кроме как получение физического контроля над выполняемой логикой?
ЗО РП/ПМ, «долой оптимизации - даешь больше фич», нехватка ресурса.. можно долго перечислять
Западные техники мониторинга команд в т.ч. скрам - не применимы к продуктовым компаниям РФ, пока существуют фундаментальные проблемы процессов. Это все только создает для рабочей среды огромную трату времени..
«Больше инспекций богу инспекций» (с)
Скоро совсем перестанет анализировать код, вернемся к временам notepad.
Тест с reactor в корне неверный. Обратитесь к документации, где четко сказано, что любое IO необходимо публиковать на выделенный Schedulers. Иначе, что вы хотите сказать графиками - reactor хуже servlet stack?
Если тестировать - то правильно. Как минимум по графикам уже понятно, чем event loop занят 99% времени.
Интересно, что же все таки случится в «правильном тесте» webflux, если добавить к вызову репозитория switch context скажем bounded elastic пул. В MVC - где тесты с тем же CompletableFuture, а как же loom вместо стандартной фабрики потока на запрос?
Описание пайплайна не верное, тест можно считать провальным.
Правильно ли понимаю, что используете нативный сокет из коробки, если да, то почему не netty?
«Локальная машина», а это лупбек. сомнительный эксперимент
Работает, не трогай! (Сбер)