Разница как минимум в том что команда судорожно сглатывает только в день Х, а в случае CD ей приходится это делать каждый час при каждом пуше.
Время деплоя может быть выбрано так чтобы минимизировать ущерб в случае проблем (выходные и прочее нерабочее время), кроме того это в любом случае предсказуемый процесс, в отличии например от автоматического деплоя который может совершенно внезапно решить обновить контейнера в кубернетесе именно в момент пиковой нагрузки. CD процесс не содержит каких либо четко сформированных релизов, это значит что либо разработку нового функционала прийдется вести с фиче-флагами (что само по себе может быть нетривиальной задачей), либо же отдельные комиты которые вливаются в основную ветку будут очень большими и будут содержать сразу всю фичу целиком, что может затруднять процесс код ревью.
Из моей практики наиболее оптимальная схема когда CD работает автоматически на всех окружениях кроме прода, а прод допустим планово обновляется раз в 2 недели (и может внепланово обновляться в случае критических проблем)
Итак, вы пишете код, отправляете его в главную ветку, ждете несколько минут и смотрите в продакшен. Все идет как надо? Или тут что-то не то?
Складывается впечатление что вы деплоите в продакшен приложение для заказа пиццы… Предположим что в результате бага в коде у вас при очередном деплое произошло необратимое повреждение данных в продакшен базе… А такое легко может случится т.к. автоматические тесты часто не могут проверить все возможные случаи или не имеют ровно такие же данные как на продакшен базе. Сколько времени займет автоматический откат таких изменений? Как много данных будет при этом потеряно? Вы точно хотите жить в ситуации когда в произвольный момент времени у вас может сложится прод? И при этом для каждой фичи на 1 строчку полезного кода вам приходится писать 10-100 строк тестового кода для того чтобы гарантировать стабильность прода.
дальнейшее выполнение программы не может быть продолжено пока не команда не завершилась успешно. Соответственно фактическое время выполнения команды load будет 1 такт если значение есть в кеше либо же 1 такт + время ожидания значения из основной памяти. Вот это время ожидание это момент когда процессор фактически простаивает и может заняться чем то другим. Out-Of-Order execution может применяться для выполенения других команд которые не зависят от ожидания значения из памяти.
Либо же можно выполнять команды из другого потока (Hyper Threading)
Все команды не могут выполнятся за один такт это явно неправда. Простейшие примеры это как раз команды доступа к памяти которые выполняются очень долго. Или например всякие команды связанные с atomic операциями, которые требуют синхронизации ядер между собой
Trigger Hook хранит свое состояние в оперативной памяти.
Каким образом реализована отказоустойчивость сервиса? Что произойдет если на любом этапе выполнения задачи один из контейнеров будет потерян? Выглядит как очередной велосипед и переизобретение условной celery (при этом у celery апи гораздо удобнее).
Вы правда не понимаете о чем вы пишете? Условный человек если это не таксист проезжает допустим 10 000 км в год и допустим за 5 лет он становится опытным водителем. Условный автопилот Теслы обучается на данных полученных с тысяч машин и соответственно за год он может обработать опыт вождения на условно 10 000 000 км дорог и побывать в 1000 раз большем количестве различных ситуаций. И соответственно этот опыт автоматически распространятся на все новые машины.
При этом большая часть ДТП как правило связана либо с нарушением правил дорожного движения, либо с потерей внимательности/реакции изза например опьянения или усталости. При том что компьютер не страдает от этого. И если автопилот будет водить на 5-10% безопастнее среднего водителя человека, то это уже уменьшит количество ДТП на дороге в десятки раз
Дело не в производительности. Проблема в том что использование swap файла мешает правильному учету памяти процесса и ломает правильную работу memory limits для контейнера. Т.е. потенциально контейнер может занимать больше памяти чем вы ему разрешили т.к. часть этой памяти вытеснена в swap файл.
По поводу пункта 1. Под в k8s может содержать более одного контейнера и при желании можно написать деплоймент так чтобы рядом с каждым экземпляром сервиса поднимался контейнер с кешом.
Но вцелом мне все таки интереснее мой первоначальный вопрос:
Есть ли статистика hit/miss и как долго отдельное значение живет в кеше?
Условный пример:
У вас есть 3 экземпляра сервиса и у каждого независимый кеш. В ходе работы какого-то бизнес процесса происходит 3 обращения к вашему сервису для получения значения. В дальнейшем в течении длительного времени это значение не используется. Для данного примера это означает что кеш абсолютно неээфективен т.к. изза лоад балансера запросы попадут на разные сервисы и во всех 3-х случаях это вызовет дорогую операцию вычисления значения.
Если учесть все сотни фреймворков которые существуют в JS, а по вашему их надо все попробовать в бою, то надо каждый новый проект писать с использованием нового фреймворка? Или сразу в одном проекте использовать 2-3 чтобы время сэкономить?
производительность ин-мемори в подавляющем большинстве случаев будет намного выше.
Зависит от конкретной задачи. Здесь как видим внезапно выяснилось что кеш работает настолько ужасно что даже сборщик мусора не справляется..
Автор не предоставил еще одну ключевую метрику без которой сложно о чем то судить:
Какой вообще общий процент кеш хит/мисс? Я подозреваю что если сборщик мусора постоянно занят уборкой вытесненных значений то кеш вообще не эффективен и просто тасует данные туда-сюда. Это также косвенно следует из того что время ответа сервиса упало весьма незначительно (в 1,8 раз) для эффективного кеша можно было бы ожидать улучшения на порядок и более.
А почему не использовали какой нибудь Memcached/Redis? Вероятно это было бы гораздо лучшее решение в плане расхода памяти вцелом т.к. кеш не дублировался бы между всеми экземплярами сервиса. Скорее всего производительность также была бы выше т.к. не было бы необходимости в сборке мусора.
Тогда получается что более высокие спутники будут работать как ретрансляторы… Это следует из самой логики… для того чтобы лазером светить с одного спутника на другой желательно чтобы их угловая скорость была минимальна… по другому прийдется делать очень сложный механизм наведения этих лазеров..
Скорее всего все спутники будут использовать одно наклонение орбиты. Это как раз позволяет им создать плотную сеть, где отдельные спутники будут смещаться друг относительно друга на небольшой скорости, что важно для организации связи между ними по лазерному лучу.
Согласен. Но иногда даже описание должности вводит в тупик. Видел на днях должность с названием "Principal Backend Engineer" описание обязанностей не содержит ни слова про программирование своими руками (на таком уровне это вцелом уже просто глупо) и вцелом 1-в-1 соответствует тому что я делал последние пару лет. Но внезапно выяснилось что эти ребята тоже расчитывают что кандидат будет писать им код в редакторе на интервью. Пришлось просто отказаться от собеседования чтобы не тратить время.
И почему перед собеседованием не вспомнить как писать хотя бы на одном каком-то языке?
Если в общем то готовиться к собеседованиям я не вижу смысла. Потому что я работаю работу и меня нанимают для того чтобы работать работу. Скилл ее работать и так растет по ходу дела. Если я буду готовиться к собеседованиям то у меня будет расти скилл "проходить собеседования". Это вцелом тоже полезный скилл и я знаю много людей которые построили с ним успешную карьеру, но мне такой вариант не нравится.
Ну и самое важное из того что тут мало обсуждается:
Собеседование это взаимный процесс, а не экзамен школьника перед преподавателем.
Если у меня будет на руках 2 оффера, на 1-м я провел условно пару часов в непринужденной атмосфере обсуждая какие нибудь интересные задачи из жизни.
На 2-м мне пришлось чувствовать себя идиотом решая идиотскую задачку в блокнотике под молчаливыми взглядами интервьювера который может решить эту задачку с завязанными глазами (потому что задает ее 5 лет подряд). Как вы думаете какой оффер я буду более склонен принять?
На своей должности мне очень редко приходиться писать код своими руками. За прошлый год например я этим занимался в лучшем случае несколько часов. Основное время уходит на постановку задач, код ревью и митинги… Поэтому иногда даже при решении простейших задач бывают проблемы типа "забыл как написать цикл на языке Х". Понятно что если мне надо писать код я могу это быстро подглядеть в мануале.
Но на собеседовании по времени не укладываюсь, и в итоге остается наполовину рабочее решение… Это и мне неприятно и думаю производит не лучшее впечатление на собеседующих. Поэтому я вцелом горячо поддерживаю идею не заниматься программированием на собеседовании.
Вот навскидку: представьте что у вас не два условия а два миллиарда.
Ну если честно ваш пример усложнения выглядит немного высосанным из пальца...
Вопрос который мне реально нравится и который тоже можно долго обсуждать это например "что происходит когда вы вбиваете в адресную строку https://google.com"
И вот тут уже можно оценить большой пласт знаний кандидата по целой куче направлений
Иногда на людей у которых мало опыта собеседований прямо реально ступор нападает и они не могут решить простейшие задачи или ответить на вопросы которые знают.
А вообще обычно все могут решить эту задачу но при этом основное внимание идет к деталям, таким как проверка границ цикла, оптимальность порядка проверок и прочие мелочи. Это как раз та причина почему я не особо люблю такие задачки, потому что для меня нормально вначале накидать решение кое-как лишь бы проверить работу идеи, а потом уже сделать несколько итераций рефакторинга чтобы довести реализацию до приемлимого уровня.
Разница как минимум в том что команда судорожно сглатывает только в день Х, а в случае CD ей приходится это делать каждый час при каждом пуше.
Время деплоя может быть выбрано так чтобы минимизировать ущерб в случае проблем (выходные и прочее нерабочее время), кроме того это в любом случае предсказуемый процесс, в отличии например от автоматического деплоя который может совершенно внезапно решить обновить контейнера в кубернетесе именно в момент пиковой нагрузки. CD процесс не содержит каких либо четко сформированных релизов, это значит что либо разработку нового функционала прийдется вести с фиче-флагами (что само по себе может быть нетривиальной задачей), либо же отдельные комиты которые вливаются в основную ветку будут очень большими и будут содержать сразу всю фичу целиком, что может затруднять процесс код ревью.
Из моей практики наиболее оптимальная схема когда CD работает автоматически на всех окружениях кроме прода, а прод допустим планово обновляется раз в 2 недели (и может внепланово обновляться в случае критических проблем)
Складывается впечатление что вы деплоите в продакшен приложение для заказа пиццы… Предположим что в результате бага в коде у вас при очередном деплое произошло необратимое повреждение данных в продакшен базе… А такое легко может случится т.к. автоматические тесты часто не могут проверить все возможные случаи или не имеют ровно такие же данные как на продакшен базе. Сколько времени займет автоматический откат таких изменений? Как много данных будет при этом потеряно? Вы точно хотите жить в ситуации когда в произвольный момент времени у вас может сложится прод? И при этом для каждой фичи на 1 строчку полезного кода вам приходится писать 10-100 строк тестового кода для того чтобы гарантировать стабильность прода.
дальнейшее выполнение программы не может быть продолжено пока не команда не завершилась успешно. Соответственно фактическое время выполнения команды load будет 1 такт если значение есть в кеше либо же 1 такт + время ожидания значения из основной памяти. Вот это время ожидание это момент когда процессор фактически простаивает и может заняться чем то другим. Out-Of-Order execution может применяться для выполенения других команд которые не зависят от ожидания значения из памяти.
Либо же можно выполнять команды из другого потока (Hyper Threading)
Все команды не могут выполнятся за один такт это явно неправда. Простейшие примеры это как раз команды доступа к памяти которые выполняются очень долго. Или например всякие команды связанные с atomic операциями, которые требуют синхронизации ядер между собой
Каким образом реализована отказоустойчивость сервиса? Что произойдет если на любом этапе выполнения задачи один из контейнеров будет потерян? Выглядит как очередной велосипед и переизобретение условной celery (при этом у celery апи гораздо удобнее).
Вы правда не понимаете о чем вы пишете? Условный человек если это не таксист проезжает допустим 10 000 км в год и допустим за 5 лет он становится опытным водителем. Условный автопилот Теслы обучается на данных полученных с тысяч машин и соответственно за год он может обработать опыт вождения на условно 10 000 000 км дорог и побывать в 1000 раз большем количестве различных ситуаций. И соответственно этот опыт автоматически распространятся на все новые машины.
При этом большая часть ДТП как правило связана либо с нарушением правил дорожного движения, либо с потерей внимательности/реакции изза например опьянения или усталости. При том что компьютер не страдает от этого. И если автопилот будет водить на 5-10% безопастнее среднего водителя человека, то это уже уменьшит количество ДТП на дороге в десятки раз
Дело не в производительности. Проблема в том что использование swap файла мешает правильному учету памяти процесса и ломает правильную работу memory limits для контейнера. Т.е. потенциально контейнер может занимать больше памяти чем вы ему разрешили т.к. часть этой памяти вытеснена в swap файл.
Испытатели чипов смогут рвать корейцев и делать более 25 кликов в секунду?
По поводу пункта 1. Под в k8s может содержать более одного контейнера и при желании можно написать деплоймент так чтобы рядом с каждым экземпляром сервиса поднимался контейнер с кешом.
Но вцелом мне все таки интереснее мой первоначальный вопрос:
Есть ли статистика hit/miss и как долго отдельное значение живет в кеше?
Условный пример:
У вас есть 3 экземпляра сервиса и у каждого независимый кеш. В ходе работы какого-то бизнес процесса происходит 3 обращения к вашему сервису для получения значения. В дальнейшем в течении длительного времени это значение не используется. Для данного примера это означает что кеш абсолютно неээфективен т.к. изза лоад балансера запросы попадут на разные сервисы и во всех 3-х случаях это вызовет дорогую операцию вычисления значения.
Если учесть все сотни фреймворков которые существуют в JS, а по вашему их надо все попробовать в бою, то надо каждый новый проект писать с использованием нового фреймворка? Или сразу в одном проекте использовать 2-3 чтобы время сэкономить?
Зависит от конкретной задачи. Здесь как видим внезапно выяснилось что кеш работает настолько ужасно что даже сборщик мусора не справляется..
Автор не предоставил еще одну ключевую метрику без которой сложно о чем то судить:
Какой вообще общий процент кеш хит/мисс? Я подозреваю что если сборщик мусора постоянно занят уборкой вытесненных значений то кеш вообще не эффективен и просто тасует данные туда-сюда. Это также косвенно следует из того что время ответа сервиса упало весьма незначительно (в 1,8 раз) для эффективного кеша можно было бы ожидать улучшения на порядок и более.
А почему не использовали какой нибудь Memcached/Redis? Вероятно это было бы гораздо лучшее решение в плане расхода памяти вцелом т.к. кеш не дублировался бы между всеми экземплярами сервиса. Скорее всего производительность также была бы выше т.к. не было бы необходимости в сборке мусора.
Тогда получается что более высокие спутники будут работать как ретрансляторы… Это следует из самой логики… для того чтобы лазером светить с одного спутника на другой желательно чтобы их угловая скорость была минимальна… по другому прийдется делать очень сложный механизм наведения этих лазеров..
Скорее всего все спутники будут использовать одно наклонение орбиты. Это как раз позволяет им создать плотную сеть, где отдельные спутники будут смещаться друг относительно друга на небольшой скорости, что важно для организации связи между ними по лазерному лучу.
Согласен. Но иногда даже описание должности вводит в тупик. Видел на днях должность с названием "Principal Backend Engineer" описание обязанностей не содержит ни слова про программирование своими руками (на таком уровне это вцелом уже просто глупо) и вцелом 1-в-1 соответствует тому что я делал последние пару лет. Но внезапно выяснилось что эти ребята тоже расчитывают что кандидат будет писать им код в редакторе на интервью. Пришлось просто отказаться от собеседования чтобы не тратить время.
Если в общем то готовиться к собеседованиям я не вижу смысла. Потому что я работаю работу и меня нанимают для того чтобы работать работу. Скилл ее работать и так растет по ходу дела. Если я буду готовиться к собеседованиям то у меня будет расти скилл "проходить собеседования". Это вцелом тоже полезный скилл и я знаю много людей которые построили с ним успешную карьеру, но мне такой вариант не нравится.
Ну и самое важное из того что тут мало обсуждается:
Собеседование это взаимный процесс, а не экзамен школьника перед преподавателем.
Если у меня будет на руках 2 оффера, на 1-м я провел условно пару часов в непринужденной атмосфере обсуждая какие нибудь интересные задачи из жизни.
На 2-м мне пришлось чувствовать себя идиотом решая идиотскую задачку в блокнотике под молчаливыми взглядами интервьювера который может решить эту задачку с завязанными глазами (потому что задает ее 5 лет подряд). Как вы думаете какой оффер я буду более склонен принять?
На своей должности мне очень редко приходиться писать код своими руками. За прошлый год например я этим занимался в лучшем случае несколько часов. Основное время уходит на постановку задач, код ревью и митинги… Поэтому иногда даже при решении простейших задач бывают проблемы типа "забыл как написать цикл на языке Х". Понятно что если мне надо писать код я могу это быстро подглядеть в мануале.
Но на собеседовании по времени не укладываюсь, и в итоге остается наполовину рабочее решение… Это и мне неприятно и думаю производит не лучшее впечатление на собеседующих. Поэтому я вцелом горячо поддерживаю идею не заниматься программированием на собеседовании.
Ну если честно ваш пример усложнения выглядит немного высосанным из пальца...
Вопрос который мне реально нравится и который тоже можно долго обсуждать это например "что происходит когда вы вбиваете в адресную строку https://google.com"
И вот тут уже можно оценить большой пласт знаний кандидата по целой куче направлений
Иногда на людей у которых мало опыта собеседований прямо реально ступор нападает и они не могут решить простейшие задачи или ответить на вопросы которые знают.
А вообще обычно все могут решить эту задачу но при этом основное внимание идет к деталям, таким как проверка границ цикла, оптимальность порядка проверок и прочие мелочи. Это как раз та причина почему я не особо люблю такие задачки, потому что для меня нормально вначале накидать решение кое-как лишь бы проверить работу идеи, а потом уже сделать несколько итераций рефакторинга чтобы довести реализацию до приемлимого уровня.