Я лет 18 на джаве разрабатываю - и до сих пор ещё не всё знаю, поэтому не совсем понимаю, что вы имеет ввиду под "время на разобраться". "Инженерная культура" - это пара процентов от того что требуется разработчику. Знания "модняцких фреймворков", инструментов, приёмов, подводных камней и пр. - это то что помогает инженеру не творить дичь, а эффективно работать.
Стоит ли писать код месяц вместо недели (да еще и наводнять его всевозможными хаками), чтобы уменьшить отклик веб-приложения с одной секунды до 10 миллисекунд?
Ну это от задачи и требований зависит - где-то стоит, а где-то нет. Что точно не стоит делать - так выполнять какие-то неосмысленные рандомные манипуляции. Оставьте это гуманитариям. Померить перформанс и найти узкое место - обычно месяц не занимает.
Там где есть БД (а в бизнес-приложениях она всегда есть) она съедает такую львиную долю производительности, что ускорение сервера приложений даже в два-три раза никто в итоге и не заметит.
Я бы так не сказал. Последние 4 месяца занимаюсь перформанс инженирингом и померил/нашёл перформанс баги где-то в 15 микросервисах, что у нас используются - обычные бизнесовые CRUD приложения. Все цифры у меня перед глазами: ускорение - в 5-100 раз в зависимости от сервиса, и оно достигается вовсе не из-за того, что база вдруг быстрее начинает работать. И даже после всех оптимизаций нет такого, что база отжирает прям "львиную долю времени" - вы переоцениваете медленность баз данных. Очень часто перформанс проседает на различных строковых операциях, аля регулярки либо парсинг JSON-ов, ещё у нас много времени тратится на парсинг строковых представлений вещественных чисел. Есть проблемы с архитектурой и как ниже правильно написали - оптимизация архитектуры - это тоже оптимизация
использование везде реляционной БД, даже не рассматривая альтернативы
Вот честно говоря, ещё не сталкивался на практике, чтобы проблемы возникали из-за реляционности базы данных.
Нет, не проще. Если нет понимания, зачем конкретно нужны ещё пара серверов.
Очень часто в бизнес приложениях код в сотни раз медленнее чем может быть. О каких "паре серверов в этом случае может идти речь"?
Оптимизациия начиняется с измерения, затем собственно оптимизации, и только после этого - математического расчёта оптимального числа серверов (если их действительно надо добавить, что далеко не всегда требуется и главное, далеко не всегда помогает)
Кварц находится на первом месте в моём топе худших либ для джава. Я вообще не понимаю тех людей которые используют её вместо Spring Schedule. Кварц - это образец оверинженеринга, дикий блакбокс с нулевой кастомизацией, который гадит в БД и делает затруднительным отладку и траблшутинг. Кто-то говорит что null - это ошибка на миллиард долларов, но на самом это место занимает quartz
Рынок как раз диктует, что зарплаты должны повышаться, если условный завод хочет себе хорошего специалиста, а они не повышаются
Зарплаты определяются спросом и предложением. Если кто-то готов работать за указанную зарплату, значит он именно столько и "стоит". Я конечно утрирую, но "хорошесть" далеко не всегда подразумевает какой-либо рост зарплат.
Надо научиться правильно ставить задачи. Не умеете? Ваши проблемы. И ваша же собственная ошибка.
А что если на вышеупомянутом заводе вообще нет задач, для которых были бы оправданы дорогие специалисты? Ну и допустим, я не умею ставить задачи. Ну и что из этого? Разве бывают идеальные люди?
Некоторые решения в автоматизации не имеют точек генерации прибыли, они предоставляют возможность для дальнейшей автоматизации, которая уже возможно будет не генерировать прибыль, а экономить на расходах, что в свою очередь будет сказываться на прибыли.
Я со своего опыта уже привык, что если что-то звучит слишком сложно, то оно ни черта не заработает и будет только приносить геморрой разным стейкхолдерам. Инженерное решение должно быть простым как топор, элегантным, удовлетворяющим всех и очевидным в своей полезности.
Я играл на детском утреннике, но потом мне сказали, что теперь снимаем блокбастер и им нужен Том Круз, а денег за него у них нет, поэтому в блокбастере сниматься буду я
Я конечно извиняюсь, но Том Круза я видел и мои знакомые тоже, и он мне принёс толику пользы. А вот ваш софт я нигде не видел и не использовал, поэтому он больше подходит в категорию местных постановок. А вот когда ваш софт будет использоваться во всех заводах РФ, или установлен на всех смартфонах или хотя бы летать на Марс, то тогда можно будет жаловаться на то что печенек не хватает.
Я не говорю, что кто-то что-то лично должен, просто к этому ведут законы рынка.
Вы принимаете за аксиому, что руководство не платит потому что жадные.
Но мне совершенно не очевидно, что команда пилящая полгода распознаватель номеров вагонов способна сгенерировать столько прибыли, чтобы оправдать свои зарплаты и соцвыплаты. Вот если бы эта команда делала софт для распознавания миллиона вагонов в день, либо тоже самое, но для 200 предприятий - тогда другое дело.
Это всё равно что играть на детском утреннике и жаловаться что гонорар меньше, чем у Том Круза в каком-нибудь блокбастере, хотя актёр на утреннике может играть ничуть не хуже!
Тут много комментариев пишут о том, что зарплаты маленькие и печенек нет.
Но с другой стороны, а возможно ли как-то по-другому, с учётом того что упомянутые решения не выходят за пределы одного предприятия?
Скажем, когда я рисую кнопку на форме, этой кнопкой пользуются миллионы человек и даже если каждый заплатит по копейке, то уже хорошо.
Разве место программиста не в тех компаниях, которые ставят своей задачей максимально широкое распространение кода? Это кстати может быть сам завод, если бы он догадался продавать вышеупомянутые решения другим предприятиям в своей области.
Другими словами, для блага всего человечества, разработчики должны перейти к подрядчику, а завод - заплатить эти 25 копеек за распознавания номера на вагоне. А на предприятии должны остаться люди которые умеют адаптировать существующий софт и дёшево/быстро реализовывать специфические нужды
Ну если отношений вообще нет, а Digma использует код, то это очевидное правонарушение. Другими словами, это Digma должна обосновать на каком основании она использует этот код.
В обычной ситуации, этим обоснованием как раз и служит лицензия GPL, которая обеспечивает законность использования Линукса (при выполнении условий). Без её наличия, никто бы не имел права использовать эту ОС без явного соглашения с её авторами.
Я не юрист, но судя по всему, Digma, с момента отказа предоставить исходный код, нарушает один из пунктов лицензии и лишается права использовать её. Теперь, если после этого она попытается продавать производные от GPL работы, то это уже нарушение закона (да, в том числе и российского)
При чём тут FSF?? Если говорить конкретно, чьи права нарушены, то это все GPL контрибьютеры, чей код (прямо либо через производные продукты) в продукции. Условие, на основание которого Digma использует код она не выполнила, следовательно она не имеет права использовать этот код напрямую, либо в производных работах. Если бы автор был бы контрибьютером, то было бы проще доказать, что он потерпевший.
Кроме того, сама идея GPL лицензии подразумевает, что кода без исходников быть не должно. В лицензии нет никакой лазейки, который позволяет обойти её основные положения. Факт нарушения есть, и он очевиден.
Не-GPL компонент, использующий GPL код должен быть отделимым, например модуль ядра или программа запускаемая на Линуксе. Например, коммерческий софт, использующий ffmpeg может вызывать её как стороннюю утилиту, но не может линковать её библиотеки.
Странно, почему вообще возникла идея переехать именно в Техас? Даже я, с США никак не связанный, знаю что там жарко. Разве в штатах мало хороших городов? Почему не Бостон, не Солт-Лейк-Сити?
Спасибо за статью, очень интересный тренд. Касаемо сайтов - тут видимо большое внимание оказывают требования по accessibility. Многие не различают красный/зелёный/жёлтые цвета - отсюда доминирование синего - он получается самый контрастный. А серые оттенки подходят вообще всем дальтоникам. Видимо отсюда же растут ноги у современных унылых оранжево-синих палитр фильмов. Старые фильмы приятнее смотреть из-за нормальных, естественных цветов. Так же заметил дизайн многих современных домов перешёл с красного или бурого кирпича на унылую бело-тёмную облицовку.
при большом числе параллельных запросов WebFlux может потреблять меньше ресурсов
Откуда у вас "большое число параллельных потоков" в машин лёрнинге? WebFlux используется, когда речь идёт о десятках тысяч одновременных соединений
Я где-то в статье сказал, что оказывает, или что Spring в целом и WebFlux в частности - это только про WEB API
WebFlux - это реактивный аналог Spring MVC. Под капотом в обоих случаях вы можете использовать как реактивный так и нереактивный API. Как веб API может повлиять на скорость мне не понятно. Вы же не запускаете обучение миллион раз в секунду.
Почему? Извините, я не нашел 100% ответа на этот вопрос с доказательствами из профайлера и хипдампов, а потратить еще несколько месяцев личного времени на поиск ответов в данный момент не готов
Если у вас появляются подозрительные результаты, то вы должны исследовать этот вопрос, ибо есть вероятность что вы что-то делаете не так. Иначе будет как в анекдоте: "стекло протирал? по колёсам бил?" WebFlux - более сложный API на его поддежку требуется больше рессурсов. И не смотря на это, вы нашли время чтобы на него переписать. А теперь пишете, что не нашли времени на ответ на вопрос: почему всё таки проседает производительность.
Не могли бы озвучить свою гипотезу по факту более эффективного управления ресурсами в WebFlux версии приложения по сравнению с Web
Моя гипотеза - что Spring Flux будет иметь такую же производительность как и Spring MVC. Чтобы точно ответить причину тормозов - надо профайлить. Bottleneck - он вcегда в неожиданном месте.
но этого оказалось достаточно, чтобы улучшить работу с ресурсами и предотвратить stop the world
зачем его предотвращать? У вас точно своп отключен?
Все работает на одной машине под управлением Windows 10 Pro
Если у вас kubernetes, почему бы не протестировать там
Есть же лаунчеры. launch4j откроет сайт где надо скачать. Можно запихнуть в установщик для вашей любимой ОС. Можно скомпилировать в нативный код. Зачем вы придумываете проблемы на ровном месте?
Даже для c++ программы иногда требуется скачивать c++ redistributable. Большинство программ требуют скачивать окружение. Претензии именно к джаве - непонятны.
Подводный камень четыре: нет готового механизма поддержания целостности локализации.
Что такое целостность локализации? ResourceBundle существует уже миллион лет
IntelliJ стала ненасытна
У JetBrains - самые популярные инструменты и они не только для Java-ы. Будете писать на руби - возьмёте ту же самую IDE.
Кто будет занимать съёмкой и расклейкой накладных экранов? Очевидно, вариант с щёткой рентабельнее. Батарея быстрее деградирует, чем что-то там сотрётся. Да и зачем что-то снимать, если её так просто "стереть"?
Как известно, реактивный стек отличается от сервлетного тем, что для выполнения одной и той же логики зачастую требуется меньше ресурсов.
Это где вы такое взяли? Обычно подразумевается что код в потоках быстрее с точки зрения throughput, но зато реактивный может быть выгоднее с точки зрения latency. Кроме того, непонятно какое вообще влияние может оказывать веб-API для обучения на основе GPU ??? Зачем там вообще нужно веб-API? Вам надо было зафиксировать какой-нибудь один веб-API и под капотом уже тестировать либо реактивный API, либо "обычный". Создаётся впечатление, что пытаетесь протестировать всё сразу, хаотично меняя какие-то параметры без нормального профайлинга и изоляции модулей. Хотелось бы видеть, скажем, "реактивный API кассандры быстрее нереактивного на таких-то запросах на 15% потому что это, это и это". Ваше же измерение абстрактного Machine Learning-а в вакууме вообще ни о чём не говорит
А вы их спрашивали? По-моему, разбираться в тонкостях вашего сервиса людям хочется ещё меньше. Кафку они хотя бы они знают и умеют с ней работать. И этот опыт трансферится в другие компании. Никаких больших сложностей в настройке я не замечал, внутренне Кафка - достаточно простая штука. Даже не понимаю о каких "сложностях" вы пишете. В спринг буте, например, обычно всё сводится к добавлению аннотации и прописыванию брокеров и топика. Если вы используете какую-то экзотику то сами с себе злобные буратины
Остался не раскрытым главный вопрос: зачем же нужна дополнительная прослойка перед Кафкой? Её API и механизм функционирования понятен и известен многим, многие имеют опыт работы с ней. Кроме того, есть комьюнити и StackOverflow где можно найти ответ на любой вопрос. Ваш сервис же не только отгрызает производительность и уменьшает надёжность, но и увеличивает объём знаний, которых надо освоить для полноценной работы.
Кроме того есть подозрение, что не все фичи Кафки поддерживаются. Как у вас обстоят дела с транзакционностью, ручным коммитами, слушателями ребалансировки? Вы поддерживаете реактивный API?
Я лет 18 на джаве разрабатываю - и до сих пор ещё не всё знаю, поэтому не совсем понимаю, что вы имеет ввиду под "время на разобраться". "Инженерная культура" - это пара процентов от того что требуется разработчику. Знания "модняцких фреймворков", инструментов, приёмов, подводных камней и пр. - это то что помогает инженеру не творить дичь, а эффективно работать.
Ну это от задачи и требований зависит - где-то стоит, а где-то нет. Что точно не стоит делать - так выполнять какие-то неосмысленные рандомные манипуляции. Оставьте это гуманитариям. Померить перформанс и найти узкое место - обычно месяц не занимает.
Я бы так не сказал. Последние 4 месяца занимаюсь перформанс инженирингом и померил/нашёл перформанс баги где-то в 15 микросервисах, что у нас используются - обычные бизнесовые CRUD приложения. Все цифры у меня перед глазами: ускорение - в 5-100 раз в зависимости от сервиса, и оно достигается вовсе не из-за того, что база вдруг быстрее начинает работать. И даже после всех оптимизаций нет такого, что база отжирает прям "львиную долю времени" - вы переоцениваете медленность баз данных. Очень часто перформанс проседает на различных строковых операциях, аля регулярки либо парсинг JSON-ов, ещё у нас много времени тратится на парсинг строковых представлений вещественных чисел. Есть проблемы с архитектурой и как ниже правильно написали - оптимизация архитектуры - это тоже оптимизация
Вот честно говоря, ещё не сталкивался на практике, чтобы проблемы возникали из-за реляционности базы данных.
Нет, не проще. Если нет понимания, зачем конкретно нужны ещё пара серверов.
Очень часто в бизнес приложениях код в сотни раз медленнее чем может быть. О каких "паре серверов в этом случае может идти речь"?
Оптимизациия начиняется с измерения, затем собственно оптимизации, и только после этого - математического расчёта оптимального числа серверов (если их действительно надо добавить, что далеко не всегда требуется и главное, далеко не всегда помогает)
Кварц находится на первом месте в моём топе худших либ для джава. Я вообще не понимаю тех людей которые используют её вместо Spring Schedule.
Кварц - это образец оверинженеринга, дикий блакбокс с нулевой кастомизацией, который гадит в БД и делает затруднительным отладку и траблшутинг.
Кто-то говорит что null - это ошибка на миллиард долларов, но на самом это место занимает quartz
Зарплаты определяются спросом и предложением. Если кто-то готов работать за указанную зарплату, значит он именно столько и "стоит". Я конечно утрирую, но "хорошесть" далеко не всегда подразумевает какой-либо рост зарплат.
А что если на вышеупомянутом заводе вообще нет задач, для которых были бы оправданы дорогие специалисты?
Ну и допустим, я не умею ставить задачи. Ну и что из этого? Разве бывают идеальные люди?
Я со своего опыта уже привык, что если что-то звучит слишком сложно, то оно ни черта не заработает и будет только приносить геморрой разным стейкхолдерам.
Инженерное решение должно быть простым как топор, элегантным, удовлетворяющим всех и очевидным в своей полезности.
Я конечно извиняюсь, но Том Круза я видел и мои знакомые тоже, и он мне принёс толику пользы.
А вот ваш софт я нигде не видел и не использовал, поэтому он больше подходит в категорию местных постановок.
А вот когда ваш софт будет использоваться во всех заводах РФ, или установлен на всех смартфонах или хотя бы летать на Марс, то тогда можно будет жаловаться на то что печенек не хватает.
Я не говорю, что кто-то что-то лично должен, просто к этому ведут законы рынка.
Вы принимаете за аксиому, что руководство не платит потому что жадные.
Но мне совершенно не очевидно, что команда пилящая полгода распознаватель номеров вагонов способна сгенерировать столько прибыли, чтобы оправдать свои зарплаты и соцвыплаты. Вот если бы эта команда делала софт для распознавания миллиона вагонов в день, либо тоже самое, но для 200 предприятий - тогда другое дело.
Это всё равно что играть на детском утреннике и жаловаться что гонорар меньше, чем у Том Круза в каком-нибудь блокбастере, хотя актёр на утреннике может играть ничуть не хуже!
Тут много комментариев пишут о том, что зарплаты маленькие и печенек нет.
Но с другой стороны, а возможно ли как-то по-другому, с учётом того что упомянутые решения не выходят за пределы одного предприятия?
Скажем, когда я рисую кнопку на форме, этой кнопкой пользуются миллионы человек и даже если каждый заплатит по копейке, то уже хорошо.
Разве место программиста не в тех компаниях, которые ставят своей задачей максимально широкое распространение кода? Это кстати может быть сам завод, если бы он догадался продавать вышеупомянутые решения другим предприятиям в своей области.
Другими словами, для блага всего человечества, разработчики должны перейти к подрядчику, а завод - заплатить эти 25 копеек за распознавания номера на вагоне.
А на предприятии должны остаться люди которые умеют адаптировать существующий софт и дёшево/быстро реализовывать специфические нужды
Никогда не понимал, что такого особенного в ОКЕАНЕ. По мне так тихое лесное озеро - гораздо круче - ни волн, ни акул, не медуз, ни опасных течений.
Ну если отношений вообще нет, а Digma использует код, то это очевидное правонарушение. Другими словами, это Digma должна обосновать на каком основании она использует этот код.
В обычной ситуации, этим обоснованием как раз и служит лицензия GPL, которая обеспечивает законность использования Линукса (при выполнении условий). Без её наличия, никто бы не имел права использовать эту ОС без явного соглашения с её авторами.
Я не юрист, но судя по всему, Digma, с момента отказа предоставить исходный код, нарушает один из пунктов лицензии и лишается права использовать её. Теперь, если после этого она попытается продавать производные от GPL работы, то это уже нарушение закона (да, в том числе и российского)
При чём тут FSF?? Если говорить конкретно, чьи права нарушены, то это все GPL контрибьютеры, чей код (прямо либо через производные продукты) в продукции. Условие, на основание которого Digma использует код она не выполнила, следовательно она не имеет права использовать этот код напрямую, либо в производных работах.
Если бы автор был бы контрибьютером, то было бы проще доказать, что он потерпевший.
Кроме того, сама идея GPL лицензии подразумевает, что кода без исходников быть не должно. В лицензии нет никакой лазейки, который позволяет обойти её основные положения. Факт нарушения есть, и он очевиден.
Не-GPL компонент, использующий GPL код должен быть отделимым, например модуль ядра или программа запускаемая на Линуксе. Например, коммерческий софт, использующий ffmpeg может вызывать её как стороннюю утилиту, но не может линковать её библиотеки.
Странно, почему вообще возникла идея переехать именно в Техас? Даже я, с США никак не связанный, знаю что там жарко. Разве в штатах мало хороших городов? Почему не Бостон, не Солт-Лейк-Сити?
Несомненно, строгая типизация уменьшает ошибки.
Я бы ещё дальше пошёл: надо сделать возможность объявлять подтипы простых типов. Скажем это не double, а литры и с килограммами их никак не сложить.
Или, допустим, это не просто строка, а SQL запрос и для присвоения строки запросу надо пропустить через escape функцию.
Такое вроде бы в Aда есть - возможно, ещё в каких-то языках присутствует?
Спасибо за статью, очень интересный тренд. Касаемо сайтов - тут видимо большое внимание оказывают требования по accessibility. Многие не различают красный/зелёный/жёлтые цвета - отсюда доминирование синего - он получается самый контрастный. А серые оттенки подходят вообще всем дальтоникам. Видимо отсюда же растут ноги у современных унылых оранжево-синих палитр фильмов. Старые фильмы приятнее смотреть из-за нормальных, естественных цветов.
Так же заметил дизайн многих современных домов перешёл с красного или бурого кирпича на унылую бело-тёмную облицовку.
Откуда у вас "большое число параллельных потоков" в машин лёрнинге? WebFlux используется, когда речь идёт о десятках тысяч одновременных соединений
WebFlux - это реактивный аналог Spring MVC. Под капотом в обоих случаях вы можете использовать как реактивный так и нереактивный API. Как веб API может повлиять на скорость мне не понятно. Вы же не запускаете обучение миллион раз в секунду.
Если у вас появляются подозрительные результаты, то вы должны исследовать этот вопрос, ибо есть вероятность что вы что-то делаете не так. Иначе будет как в анекдоте: "стекло протирал? по колёсам бил?"
WebFlux - более сложный API на его поддежку требуется больше рессурсов. И не смотря на это, вы нашли время чтобы на него переписать. А теперь пишете, что не нашли времени на ответ на вопрос: почему всё таки проседает производительность.
Моя гипотеза - что Spring Flux будет иметь такую же производительность как и Spring MVC. Чтобы точно ответить причину тормозов - надо профайлить. Bottleneck - он вcегда в неожиданном месте.
зачем его предотвращать? У вас точно своп отключен?
Если у вас kubernetes, почему бы не протестировать там
Есть же лаунчеры. launch4j откроет сайт где надо скачать. Можно запихнуть в установщик для вашей любимой ОС. Можно скомпилировать в нативный код.
Зачем вы придумываете проблемы на ровном месте?
Даже для c++ программы иногда требуется скачивать c++ redistributable. Большинство программ требуют скачивать окружение. Претензии именно к джаве - непонятны.
Что такое целостность локализации? ResourceBundle существует уже миллион лет
У JetBrains - самые популярные инструменты и они не только для Java-ы. Будете писать на руби - возьмёте ту же самую IDE.
Кто будет занимать съёмкой и расклейкой накладных экранов? Очевидно, вариант с щёткой рентабельнее. Батарея быстрее деградирует, чем что-то там сотрётся. Да и зачем что-то снимать, если её так просто "стереть"?
Это где вы такое взяли? Обычно подразумевается что код в потоках быстрее с точки зрения throughput, но зато реактивный может быть выгоднее с точки зрения latency.
Кроме того, непонятно какое вообще влияние может оказывать веб-API для обучения на основе GPU ??? Зачем там вообще нужно веб-API?
Вам надо было зафиксировать какой-нибудь один веб-API и под капотом уже тестировать либо реактивный API, либо "обычный".
Создаётся впечатление, что пытаетесь протестировать всё сразу, хаотично меняя какие-то параметры без нормального профайлинга и изоляции модулей.
Хотелось бы видеть, скажем, "реактивный API кассандры быстрее нереактивного на таких-то запросах на 15% потому что это, это и это". Ваше же измерение абстрактного Machine Learning-а в вакууме вообще ни о чём не говорит
А вы их спрашивали? По-моему, разбираться в тонкостях вашего сервиса людям хочется ещё меньше. Кафку они хотя бы они знают и умеют с ней работать. И этот опыт трансферится в другие компании. Никаких больших сложностей в настройке я не замечал, внутренне Кафка - достаточно простая штука. Даже не понимаю о каких "сложностях" вы пишете.
В спринг буте, например, обычно всё сводится к добавлению аннотации и прописыванию брокеров и топика. Если вы используете какую-то экзотику то сами с себе злобные буратины
Остался не раскрытым главный вопрос: зачем же нужна дополнительная прослойка перед Кафкой? Её API и механизм функционирования понятен и известен многим, многие имеют опыт работы с ней. Кроме того, есть комьюнити и StackOverflow где можно найти ответ на любой вопрос. Ваш сервис же не только отгрызает производительность и уменьшает надёжность, но и увеличивает объём знаний, которых надо освоить для полноценной работы.
Кроме того есть подозрение, что не все фичи Кафки поддерживаются. Как у вас обстоят дела с транзакционностью, ручным коммитами, слушателями ребалансировки? Вы поддерживаете реактивный API?
Только я удивлён что MX Linux является самым популярным дистрибутивом?