В статье проводится сравнение между "EmbeddedKafka с GraalVM" и confluentinc/cp-kafka. При этом разницу в объеме используемой памяти и скорости запуска следует рассматривать именно в рамках этого контекста. Я согласен с тем, что только использование GraalVM не всегда может привести к значительной разнице в потреблении памяти, но в случае скорости запуска влияние может быть значительным. Следует также учитывать, что анализ ведется в контексте последовательного запуска относительно простых интеграционных тестов, где требуется минимальная ресурсная конфигурация для запуска.
Спасибо за вопрос. Провел серию тестов производительности с использованием JMH для оценки времени запуска и операционной готовности различных конфигураций контейнеров Kafka, статью дополнил. Для оценки памяти я использовал docker stats.
Спасибо за статью. У меня есть пара вопросов, если можно.
1 А чем такой подход выигрывает у того, когда можно собрать jar через gradle плагин application и просто положить его в образ?
2 Касательно этого:
Это однозначный плюс для безопасности, так как структура каждого образа известна и исключается попадание на прод «левых» библиотек.
Мне кажется, что использование образов докера само по себе реализует этот эффект — «исключается попадание на прод «левых» библиотек», т.е. на прод пойдет то, что «разработчик» собрал.
Интересная статья, не знал что в spring и такое уже завезли.
А для решения подобных задач вы не смотрели в сторону bpmn или drools? Если в первой, как мне кажется, сложные графы переходов РИСОВАТЬ проще, то вторая дюже удобна, когда много мелкой логики.
Вы не хотите меня услышать — если ваши примеры написать на java грамотно, то в них не будет тех выдуманных проблем, что вы пытаетесь решить.
Я допускаю, что вы плохие примеры привели, хотя после исправления они не стали лучше :/
Это не документация, это сравнение возможностей языка через призму примеров из плохо написанного кода. Профанация.
Вы это тут пишите, народ потом читает и начинает перешептываться. И в итоге мы имеем
В последнее время я часто слышу о том, что Java стала устаревшим языком, на котором сложно строить большие поддерживаемые приложения
Согласен. И в комментариях к статье я выразил всё своё беспокойство касательно того, что в угоду доказательства «бессильности» java вы приводите в пример плохо написанный код.
Не понимаю вас. Вот вы получаете Optional из spring data, а я нет — я всегда объекты или null.
И вы со временем хотите поменять что? реализацию spring data?
Не понимаю, как «это» следует из моего утверждения. Но вы же понимаете, что не база вам optional возвращает, а вы в него ответ где-то завернете, так же?
Я имел ввиду, чтобы дизайн кода должен быть таким, чтобы код бизнес логики был отделен от контекста ее использования и про него не знал.
Например существует метод Math.max(), это хороший метод. Могу ли я его использовать в «асинхронных» вычислениях? Могу. Нужно ли методу в контракте иметь CompletableFuture или Optional? Нет, не нужно.
Прошу обратить внимание на версии, указанные в readme проекта https://github.com/avvero/embedded-kafka
Я подумаю над тем, как это лучше переформулировать. Дополнительно приложил анализ логов GC, надеюсь это поможет улучшить представление.
В статье проводится сравнение между "EmbeddedKafka с GraalVM" и
confluentinc/cp-kafka. При этом разницу в объеме используемой памяти и скорости запуска следует рассматривать именно в рамках этого контекста. Я согласен с тем, что только использование GraalVM не всегда может привести к значительной разнице в потреблении памяти, но в случае скорости запуска влияние может быть значительным. Следует также учитывать, что анализ ведется в контексте последовательного запуска относительно простых интеграционных тестов, где требуется минимальная ресурсная конфигурация для запуска.Спасибо за вопрос. Провел серию тестов производительности с использованием JMH для оценки времени запуска и операционной готовности различных конфигураций контейнеров Kafka, статью дополнил.
Для оценки памяти я использовал docker stats.
Нет, не думал над этим
Отличное замечение! Но мне кажется, что использование такого подхода хоть и повысит читаемость кода, но не решит описанную проблему, а лишь скроет ее.
А вы до собесов свои желания по условиям озвучивали?
1 А чем такой подход выигрывает у того, когда можно собрать jar через gradle плагин application и просто положить его в образ?
2 Касательно этого: Мне кажется, что использование образов докера само по себе реализует этот эффект — «исключается попадание на прод «левых» библиотек», т.е. на прод пойдет то, что «разработчик» собрал.
А для решения подобных задач вы не смотрели в сторону bpmn или drools? Если в первой, как мне кажется, сложные графы переходов РИСОВАТЬ проще, то вторая дюже удобна, когда много мелкой логики.
Я допускаю, что вы плохие примеры привели, хотя после исправления они не стали лучше :/
Вы это тут пишите, народ потом читает и начинает перешептываться. И в итоге мы имеем
И вы со временем хотите поменять что? реализацию spring data?
Мы же с вами на одной волне!
Например существует метод Math.max(), это хороший метод. Могу ли я его использовать в «асинхронных» вычислениях? Могу. Нужно ли методу в контракте иметь CompletableFuture или Optional? Нет, не нужно.