Нет, конечно, я про размер оперативки для контейнера, содержащего работающий сервис. Но интеграция с etcd (а зачем оно нужно, кстати, лидер в кафке не в etcd живет), https, s3 не требует кучи памяти. Как и несколько небольших кэшей, хотя все зависит от размера записей в кэше, если там по 10тысяч элементов по килобайту, то они уже 20 мегабайт съедят.
Другое дело, что обычно на Java/Kotlin сделают все на спринге, что позволит потратить на подобные задачи в два раза времени, хотя, конечно, при этом уже нужно будет 128 оперативки, а не 90, но это обычно всем пофиг.
Хм, и в чем проблема? Даже приложение на спринге упаковывают в 64MB памяти и это без GraalVM. После появления модульности появилась возможность очень сильно уменьшать расходы на системные библиотеки, а в остальном все зависит от подхода к разработке. Да, обычно это нафиг никому не нужно, нет разницы между 64 или 128MB и задачи оптимизировать модули нет. Но никаких принципиальных проблем нет.
Ну, вообще очень давно JIT дает более оптимальный код, чем AOT, в чем проблема-то? Данных при выполнении больше, поэтому больше оптимизаций доступно. Да, в JIT сложно с глобальными оптимизациями, но их и в AOT мало кто делает (да и время компиляции взлетает неимоверно).
Понятно, что это не про всякий JIT, но JVMовский долго вылизовали и денег туда вбухано неимоверно.
Ну вот JIT - это оптимизации PGO, только выполняемые прямо во время исполнения и подстраивающиеся при изменении профиля. Ну и с некоторыми дополнительными фенечками, которые в статике сложно реализовать. А что так поздно PGO появился в GO? В GraalVM он еще с 19го года, как раз чтобы хоть как-то JIT догнать по производительности. Ну и не так давно в Hotspot тоже добавили профилирование JIT на старте (а в других-то JVMках оно было очень давно).
Если код выполняется ровно один раз - то, конечно, скомпилированный быстрее. Если его нужно выполнить миллион раз (а на бэкенде обычно именно такие сценарии), то потери на обвязку реального кода уже не так важны, а вот оптимизации под конкретные сценарии очень даже существенны. Но для однократных скриптов вообще быстрее какой-нибудь пайтон взять. А вот для нагруженного бэкенда - уже совсем другая история.
Впрочем, на реальную производительность гораздо больше влияет качество библиотек, особенности конфигурации GC и прочие мелочи. Которые пока лучше в JVM (но, может быть, лет за десять golang и догонит).
Потому на каком-нибудь techempower java стабильно (кроме одного теста) обгоняет Go. Впрочем, rust еще быстрее почти всегда.
Ну, вообще перекладывать 100 сообщений в секунду на 0.01% CPU и 90MB можно и на java сделать. Не делают, так как нет смысла ради сотни мегабайт идти в оптимизированные фреймворки и проще воткнуть тот же Spring. Но технически проблем нет.
В нашем. У JIT больше данных для оптимизаций, нежели у компилятора, поэтому он выдает более эффективный код. Это же не интерпретация, это как раз про компиляцию. Но JIT знает про конкретные паттерны использования кусочков кода, про статистику переходов и так далее. Топопвые JIT-компиляторы на Java дают большую производительность для соответствующих кейсах. Но, конечно, нужно набирать соответствующий статистику. Тот же Go медленнее нормального кода на Java.
Хм, вообще-то JIT должен (и дает) большую производительность, нежели статически скомпилированный код. В любом случае, код на сервере никак не влияет на скорость выполнения запросов на СУБД. Горутины никак не помогают выполнять запросы на СУБД (скорее мешают, кстати).
Про что статья - не понятно. Советы пригодны для какого-то pet project, на продакшене большая часть рекомендаций неприемлима. Некоторые советы вообще опасны и могут привести к длительным простоям. Реальных проблем не затронуто вообще никаких. Впрочем, изначальная статья - это рекламный пост от JetBrains, там и не должно быть какого-то содержания, так как функциональность генерации миграций очень ограниченная и, в реальных проектах, бесполезная.
Согласно RFC 7519, JWT могут шифроваться. Если хочется скрыть информацию в токене, то кто мешает использовать стандартное для этого решение с зашифрованным payload.
Вообще, в статье путается управление сессиями, стандарты аутентификации и формат упаковки данных. JWT легко может храниться в куке и содержать sessionId и еще какие-то параметры, как стандартный и удобный контейнер.
А вот стоит ли для авторизации приложения в браузере использовать OAuth2 или что-то другое - совершенно отдельный вопрос. На мой взгляд, для авторизации и аутентификации можно и нужно строить схемы из нескольких токенов, часть из которых хранится в http-only куках на специальном поддомене. Но это уже про довольно сложную схему из трех токенов, частой смены access-token (нужной для обнаружения компрометации, а не для защиты) и не самую тривиальную логик проверки. Но зато это горадо надежнее хранения sessionId
Ага. Я долго смотреть на Zf, но понял, что без грипа он крайне неудобен, а с накладным грипом становится слишком громоздким и лучше уже брать что-то постарше. Так и сижу со своим D750, ничего заметно лучше пока нет (
Странно, что люди используют REST для создания API и ссылаются на Филдинга, который явно писал, что REST - это подход для гипермедиа систем, а не для проектирования API. Собственно, в большей части проектов выбор REST (уровня зрелости 2 и выше) является архитектурной ошибкой. Тем более для взаимодействия внутри системы.
Забавно, что автор при этом не знает азов скрама, хотя и рассуждает о работе скрам-мастера. Про аджайл, кстати, тоже не знает, хотя и говорит о каких-то аджайл-метриках.
Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для http это сделать легко, а вот для кафки - сложно), о чем, собственно и идет обсуждение в этой статье. Для выкладки мало "выложить новый код", нужно еще разобраться с его независимым тестированием, канарейкой, контролем потребления ресурсов и так далее. Да, все эти задачи, конечно, можно решить и на эрланге/элексире. Но, увы, плюс "перезагрузка модулей" не перекрывает минусов экосистемы Erlang (неторопливое исполнение, редкие и дорогие разработчики, относительно бедная экосистема).
Релоад кусочков кода в рамках одного сервиса - это достаточно просто и есть много где. И, в общем-то, нафиг не нужно. Но это очень небольшая часть логики обновления сложного продукта.
Но это скорее инструмент для развертывания окружения с нуля, не для обновления решения на продакшене, где декларативный стиль не спасает, увы. И тогда особой разницы с ансиблом или паппетом не заметно (ну, может код не такой кривой получается, но это уже надо вглубь погружаться). Но нормальных инструментов для развертывания сложного продакшена без останова, увы, вообще нет на рынке. Все пытаются изображать декларативный стиль, хотя обычно важнее как раз сделать удобным императивный (
Ээ, в чем проблема в алгоритме бинарного поиска, какие там баги изобретатель отыскивал? Может, простую идею поиска в отсортированном массиве спутали с чем-то еще?
Нет, конечно, я про размер оперативки для контейнера, содержащего работающий сервис.
Но интеграция с etcd (а зачем оно нужно, кстати, лидер в кафке не в etcd живет), https, s3 не требует кучи памяти. Как и несколько небольших кэшей, хотя все зависит от размера записей в кэше, если там по 10тысяч элементов по килобайту, то они уже 20 мегабайт съедят.
Другое дело, что обычно на Java/Kotlin сделают все на спринге, что позволит потратить на подобные задачи в два раза времени, хотя, конечно, при этом уже нужно будет 128 оперативки, а не 90, но это обычно всем пофиг.
Хм, и в чем проблема? Даже приложение на спринге упаковывают в 64MB памяти и это без GraalVM. После появления модульности появилась возможность очень сильно уменьшать расходы на системные библиотеки, а в остальном все зависит от подхода к разработке.
Да, обычно это нафиг никому не нужно, нет разницы между 64 или 128MB и задачи оптимизировать модули нет. Но никаких принципиальных проблем нет.
Ну, вообще очень давно JIT дает более оптимальный код, чем AOT, в чем проблема-то? Данных при выполнении больше, поэтому больше оптимизаций доступно. Да, в JIT сложно с глобальными оптимизациями, но их и в AOT мало кто делает (да и время компиляции взлетает неимоверно).
Понятно, что это не про всякий JIT, но JVMовский долго вылизовали и денег туда вбухано неимоверно.
Ну вот JIT - это оптимизации PGO, только выполняемые прямо во время исполнения и подстраивающиеся при изменении профиля. Ну и с некоторыми дополнительными фенечками, которые в статике сложно реализовать.
А что так поздно PGO появился в GO? В GraalVM он еще с 19го года, как раз чтобы хоть как-то JIT догнать по производительности.
Ну и не так давно в Hotspot тоже добавили профилирование JIT на старте (а в других-то JVMках оно было очень давно).
Полного актуального списка я за пять минут не нашел, можно посмотреть на https://advancedweb.hu/profile-based-optimization-techniques-in-the-jvm/
Но это для довольно старой версии JVM, с тех пор еще что-то добавили.
Если код выполняется ровно один раз - то, конечно, скомпилированный быстрее. Если его нужно выполнить миллион раз (а на бэкенде обычно именно такие сценарии), то потери на обвязку реального кода уже не так важны, а вот оптимизации под конкретные сценарии очень даже существенны.
Но для однократных скриптов вообще быстрее какой-нибудь пайтон взять. А вот для нагруженного бэкенда - уже совсем другая история.
Впрочем, на реальную производительность гораздо больше влияет качество библиотек, особенности конфигурации GC и прочие мелочи. Которые пока лучше в JVM (но, может быть, лет за десять golang и догонит).
Потому на каком-нибудь techempower java стабильно (кроме одного теста) обгоняет Go. Впрочем, rust еще быстрее почти всегда.
Ну, вообще перекладывать 100 сообщений в секунду на 0.01% CPU и 90MB можно и на java сделать. Не делают, так как нет смысла ради сотни мегабайт идти в оптимизированные фреймворки и проще воткнуть тот же Spring. Но технически проблем нет.
В нашем. У JIT больше данных для оптимизаций, нежели у компилятора, поэтому он выдает более эффективный код. Это же не интерпретация, это как раз про компиляцию. Но JIT знает про конкретные паттерны использования кусочков кода, про статистику переходов и так далее.
Топопвые JIT-компиляторы на Java дают большую производительность для соответствующих кейсах. Но, конечно, нужно набирать соответствующий статистику.
Тот же Go медленнее нормального кода на Java.
Хм, вообще-то JIT должен (и дает) большую производительность, нежели статически скомпилированный код. В любом случае, код на сервере никак не влияет на скорость выполнения запросов на СУБД.
Горутины никак не помогают выполнять запросы на СУБД (скорее мешают, кстати).
Про что статья - не понятно.
Советы пригодны для какого-то pet project, на продакшене большая часть рекомендаций неприемлима. Некоторые советы вообще опасны и могут привести к длительным простоям. Реальных проблем не затронуто вообще никаких.
Впрочем, изначальная статья - это рекламный пост от JetBrains, там и не должно быть какого-то содержания, так как функциональность генерации миграций очень ограниченная и, в реальных проектах, бесполезная.
Согласно RFC 7519, JWT могут шифроваться. Если хочется скрыть информацию в токене, то кто мешает использовать стандартное для этого решение с зашифрованным payload.
Вообще, в статье путается управление сессиями, стандарты аутентификации и формат упаковки данных.
JWT легко может храниться в куке и содержать sessionId и еще какие-то параметры, как стандартный и удобный контейнер.
А вот стоит ли для авторизации приложения в браузере использовать OAuth2 или что-то другое - совершенно отдельный вопрос. На мой взгляд, для авторизации и аутентификации можно и нужно строить схемы из нескольких токенов, часть из которых хранится в http-only куках на специальном поддомене. Но это уже про довольно сложную схему из трех токенов, частой смены access-token (нужной для обнаружения компрометации, а не для защиты) и не самую тривиальную логик проверки. Но зато это горадо надежнее хранения sessionId
Так куча вариантов. RPC в виде json-over-http (например, в стиле REST Level 1 по Ричардсону), GRPC (если есть подходящий мэш).
Ага. Я долго смотреть на Zf, но понял, что без грипа он крайне неудобен, а с накладным грипом становится слишком громоздким и лучше уже брать что-то постарше.
Так и сижу со своим D750, ничего заметно лучше пока нет (
Странно, что люди используют REST для создания API и ссылаются на Филдинга, который явно писал, что REST - это подход для гипермедиа систем, а не для проектирования API.
Собственно, в большей части проектов выбор REST (уровня зрелости 2 и выше) является архитектурной ошибкой. Тем более для взаимодействия внутри системы.
Забавно, что автор при этом не знает азов скрама, хотя и рассуждает о работе скрам-мастера.
Про аджайл, кстати, тоже не знает, хотя и говорит о каких-то аджайл-метриках.
Я все это знаю. Но это действительно не очень значимый плюс для выкладки больших систем, где нужно разбираться еще с миграцией баз данных, с нетривиальными миграциями на взаимодействий сервисов (для http это сделать легко, а вот для кафки - сложно), о чем, собственно и идет обсуждение в этой статье.
Для выкладки мало "выложить новый код", нужно еще разобраться с его независимым тестированием, канарейкой, контролем потребления ресурсов и так далее. Да, все эти задачи, конечно, можно решить и на эрланге/элексире. Но, увы, плюс "перезагрузка модулей" не перекрывает минусов экосистемы Erlang (неторопливое исполнение, редкие и дорогие разработчики, относительно бедная экосистема).
Ну, во многих реальных ситуациях, увы, можно сделать только массогабаритный макет.
Впрочем, обычно его и достаточно )
Релоад кусочков кода в рамках одного сервиса - это достаточно просто и есть много где. И, в общем-то, нафиг не нужно.
Но это очень небольшая часть логики обновления сложного продукта.
Но это скорее инструмент для развертывания окружения с нуля, не для обновления решения на продакшене, где декларативный стиль не спасает, увы. И тогда особой разницы с ансиблом или паппетом не заметно (ну, может код не такой кривой получается, но это уже надо вглубь погружаться).
Но нормальных инструментов для развертывания сложного продакшена без останова, увы, вообще нет на рынке. Все пытаются изображать декларативный стиль, хотя обычно важнее как раз сделать удобным императивный (
Ээ, в чем проблема в алгоритме бинарного поиска, какие там баги изобретатель отыскивал? Может, простую идею поиска в отсортированном массиве спутали с чем-то еще?