Комментарии 11
Я так понял у вас был алгоритм, который выполнялся в одном потоке с последовательной цепочкой вызовов операций. Вы же оценили зависимости и переделали алгоритм так чтобы какие-то его части выполнялись параллельно. Так? Я понимаю что за счет параллельности это может привести к ускорению каждого отдельного запроса, но вот как это улучшило читабельность кода? По мне так это наоборот должно было существенно усложнить код.
второй вопрос. А что именно вы оптимизировали? Время обработки отдельного запроса (latency) или общую пропускную способность? (Throughput). Если latency, то ок. Но если пропускную способность, то тогда почему просто нельзя было увеличивать число экземпляров сервисов (или потоков) без перехода на параллельность?
Возможно, разбиение на классы помогло разделить логи на части по типу логгера и тем самым отследить вес частей сервиса с точки зрения нагрузки. В целом согласен, что "читаемость" без примеров сложно измерить и оценить читателям, да и разбить на классы можно как грамотно, так и бездарно, просто усложнив путь при чтении кода.
Спасибо за статью, довольно неожиданное применение теории графов. Видел подобные рассуждения в сфере управления проектами, но внутри одного микросервиса такое увидеть нетривиально.
Нашли критические операции, которые стоит оптимизировать
Есть такая штука, как casual profiling - для автоматизации поиска узких мест. И не надо самому сидеть и графы зависимостей рисовать и время подсчитывать с помощью логов. Для Java есть соответствующий инструмент.
Для многих систем есть профайлеры в том или ином виде. Которые позволяют видеть картину целиком - что где сколько времени и ресурсов занимает.
И кроме компонентного, бизнес и интеграционного тестирования есть еще нагрузочное. Которое предназначено как раз для оценки производительности.
И проблемы производительности иногда связаны не с какими-то частными узкими местами, а с архитектурой в целом, которая эти места создает.
Те же микросервисы - да, это очень концептуально. Но. Вот есть два микросервиса. А и Б. Они взаимодействуют друг с другом (и ни с кем больше). И обмениваются некоторыми пакетами с заданной структурой. При этом один упаковывает пакет в json, отправляет его другому. Тот распаковывает, обрабатывает, ответ опять запаковывает в json и отправляет обратно.
Вроде бы все красиво и концептуально. Но. запаковка-распаковка json не бесплатна. На это уходит время и ресурсы. И если вариативность структуры пакета невелика, то куда эффективнее пакеты оформлять в виде двоичной датаграммы (или набора датаграмм) и не тратить время на возню с json.
А может быть вообще объединить несколько микросервисов в один актор с заданным функционалом.
Все это частности, конечно, но любая оптимизация идет от архитектуры изначально.
когда увидел слово "Заключение", но так и не увидел математику - стало печально от прочтения очередной статьи не соответствующей заголовку.
1) Нагрузка увеличилась в 2000 раз, вы увеличили скорость одного из сервисов в меньше чем 2 раза - фейл.
2) разброс методов по классам не даёт ровно ничего в плане читаемости. Переименование методов и расщепление их на более мелкие, если нужно - даёт.
3) В статье говорится:
Итак, у нас есть сервис, организованный как последовательное выполнение затратных по времени операций, которые зависят друг от друга.
Зависят! А потом выясняется, что "не всё так однозначно" (это обман читателя). Так это самый элементарный и первый способ оптимизации длинной цепочки операций - найти независимые части в последовательности и выполнять их параллельно. Нахождение критического пути и подлежащих оптимизации операций в таком простом графе - дело взгляда на граф в течение 10 секунд. Теория графов тут вообще не нужна.
В общем, работа, достойная джуна, но никак не кандидата наук, главного (!) разработчика.
С одной стороны, когда я читал статью, то у меня складывалось такое же впечатление. Видимо, ожидания были завышены - ожидал увидеть тонны матана, а тут математика на уровне школы.
Вместе с этим, не могу согласиться насчёт "работа, достойная джуна". Раз этим занимался главный разработчик, то джуны, как и миддлы, решить описанную проблему не смогли
Ага, тож испытал испанский стыд при прочтении...
Скачайте демо-версию Спайдер, там ограничение 40 операций. Будет вам и критический путь и позднее расписание за секунду.
Ускоряем приложение: никаких фреймворков — только математика