xhprof хорош (и даже научился сохранять полные цепочки, а не только рёбра, как раньше), но требует дополнительных телодвижений для настройки, а древний монолит лишний раз трогать страшно. А тут удалось не только использовать фишки перфоратора (например, агрегацию профилей), но и принести глобальную пользу
Если бы не ИИ, я бы вообще за это не взялся, ведь «работает — не трогай», и есть более приоритетные задачи. А задача «понять, куда уходит столько CPU» зависла бы в беклоге
Если в R под реактивностью имеются в виду ленивые вычисления, то польза от них очевидна: без них не работало бы nonstandard evaluation, на котором основаны dplyr, data.table и многое другое. Всё это работает так удобно благодаря тому, что аргументы функции не вычисляют сразу, и с ними можно работать, как с выражениями
У нас есть тестовый кластер, куда ходят микросервисы из тестовой среды, и там всё работает в целом хорошо. Правда, периодически приходится терминировать workflow, которые паникуют из-за того, что в тестинг были выкачены изменения, ломающие детерминизм (что вообще штатная ситуация для тестинга).
У нас есть отдельная команда, которая занимается внутренними инсталляциями Temporal и его тюнингом. Подробностей я не знаю, но, в частности, в хранилище используется YDB (сам слой персистентности доступен в open source: https://github.com/yandex/temporal-over-ydb)
Да, формулировка получилась не очень. Я имел в виду следующее: например, при создании заказа нужно выполнить довольно много действий. При этом результат некоторых действий требуется для некоторых других, а кроме того, падение одних действий можно игнорировать, падение других требует фоллбеков, а падение третьих приводит к невозможности дальнейшей обработки.
В старой парадигме (на очередях и стейт-машине) большая часть этих действий выполнялась последовательно, чтобы не усложнять дополнительно код, и так усложнённый асинхронными вызовами и фоллбеками. Temporal позволяет гораздо лучше сфокусироваться на бизнес-логике, и правильно расписать зависимости между действиями, не запутывая код настолько, что его невозможно будет поддерживать.
Поэтому даже с дополнительными задержками на взятие задач в работу весь этап завершается заметно быстрее
с Perfect я никогда не имел дело, но судя по сайту, у них нет такого акцента на надёжность и воспроизводимость бизнес-логики, как у темпорала, и он не построен на event sourcing, а просто поддерживает кеширование промежуточных результатов пайплайна. Поэтому у меня пока сложилось впечатление, что Perfect гораздо ближе по замыслу к Airflow
Тут довольно тонкий момент. Некоторые изменения — например, изменение продолжительности таймера, или изменение аргументов вызова Activity — не приводят к недетерминизму (вот здесь подробнее). Кроме того, мы вольны менять код activity вообще в любой момент, на них требования детерминизма не распространяются
А что делать, если его надо изменить?
Тут возможны разные варианты действий в зависимости от конкретной ситуации. Если воркфлоу паникует и не может пройти какой-то шаг, то здесь просто поможет релиз исправленного кода воркфлоу. Если workflow завис в бесконечном ожидании, то после выкатки новой версии кода можно его reset-нуть, и бизнес-логика будет выполняться заново (вместе со всеми activity) с того места, на который reset-нули. В принципе в большинстве случаев reset должен помочь — даже есть воркфлоу пошёл неправильно и уже закончился, мы всё равно сможем его reset-нуть.
По сути своей reset — это terminate исходного воркфлоу и копирование какой-то части истории в новый, который и продолжит выполняться
Перезапуск сервера Temporal приводит к остановке процессов, или они восстанавливаются в той же точке с тем же контекстом?
Всё восстановится в той же самой точке, потому что в истории событий в БД хранится вся необходимая информация, все остальные компоненты, в общем, stateless. Так, например, можно спокойно остановить сервер, обновить его, и запустить заново, единственным эффектом будет задержка выполнения действий на время этой операции
Безопаснее это на уровне железки сделать. Дублирование экранов, на втором настраиваешь зум. С точки зрения софта система чиста, разве что два монитора в режиме повторения. Но вряд ли это будет подозрительно
А можно было бы здесь, собственно, отображаемый пользователю адрес почты (strong.text-almost-black) сделать заблокированным инпутом с особым оформлением (чтобы просто выглядело как текст)? Тогда, кажется, и дублирование не понадобится.
Другое дело, что я часто встречаю формы из двух экранов — на первом только логин, на втором только пароль. Вот тут без скрытого поля уже очевидно никак
Не смог быстро найти инструкцию ручного развёртывания сервера на своём VPS. Такая есть? Не могу себе позволить вводить реквизиты от рутового доступа куда-то, кроме ssh-клиента
Оригинальные терминалы в маке тоже подтормаживали. У меня даже закрадывались мысли, что тормоза там специально, чтобы снизить нагрузку на кухню, ибо тормозило именно тогда, когда много заказов — впрочем, плохая оптимизация будет выглядеть так же
У нас на подъезде был именно такой классический «Сезам», абонентское устройство ровно как на фото. Установили его где-то между 1998 и 2000. Помню, что пластмассовые ключи были дешевле в заказе, но ломались в кармане очень просто, поэтому довольно быстро все сделали металлические.
Главная проблема у нашего была в том, что у него очень быстро стали мутными окошки для цифр, да и сами цифры с дисков стёрлись. Поэтому набирать их приходилось наощупь по оставшимся видимыми цифрам. И заодно привычка — сбрасывать цифры после того, как набрал свою квартиру, на всякий случай
xhprof хорош (и даже научился сохранять полные цепочки, а не только рёбра, как раньше), но требует дополнительных телодвижений для настройки, а древний монолит лишний раз трогать страшно. А тут удалось не только использовать фишки перфоратора (например, агрегацию профилей), но и принести глобальную пользу
Если бы не ИИ, я бы вообще за это не взялся, ведь «работает — не трогай», и есть более приоритетные задачи. А задача «понять, куда уходит столько CPU» зависла бы в беклоге
Это же запчасти Shiny. Для интерактивных штук реактивность в целом максимально полезна (не пересчитывать то, что пересчитывать не нужно)
Если в R под реактивностью имеются в виду ленивые вычисления, то польза от них очевидна: без них не работало бы nonstandard evaluation, на котором основаны dplyr, data.table и многое другое. Всё это работает так удобно благодаря тому, что аргументы функции не вычисляют сразу, и с ними можно работать, как с выражениями
3000 калорий в день эквивалентны примерно 150 Вт. ИИ пока до такой эффективности очень далеко
У нас есть тестовый кластер, куда ходят микросервисы из тестовой среды, и там всё работает в целом хорошо. Правда, периодически приходится терминировать workflow, которые паникуют из-за того, что в тестинг были выкачены изменения, ломающие детерминизм (что вообще штатная ситуация для тестинга).
Таких длинных воркфлоу у нас нет, они ограничены максимальным временем жизни заказа (точнее, максимальным сроком заказа заранее)
Десятки тысяч running workflow в моменте для нас норма
У нас есть отдельная команда, которая занимается внутренними инсталляциями Temporal и его тюнингом. Подробностей я не знаю, но, в частности, в хранилище используется YDB (сам слой персистентности доступен в open source: https://github.com/yandex/temporal-over-ydb)
Да, формулировка получилась не очень. Я имел в виду следующее: например, при создании заказа нужно выполнить довольно много действий. При этом результат некоторых действий требуется для некоторых других, а кроме того, падение одних действий можно игнорировать, падение других требует фоллбеков, а падение третьих приводит к невозможности дальнейшей обработки.
В старой парадигме (на очередях и стейт-машине) большая часть этих действий выполнялась последовательно, чтобы не усложнять дополнительно код, и так усложнённый асинхронными вызовами и фоллбеками. Temporal позволяет гораздо лучше сфокусироваться на бизнес-логике, и правильно расписать зависимости между действиями, не запутывая код настолько, что его невозможно будет поддерживать.
Поэтому даже с дополнительными задержками на взятие задач в работу весь этап завершается заметно быстрее
с Perfect я никогда не имел дело, но судя по сайту, у них нет такого акцента на надёжность и воспроизводимость бизнес-логики, как у темпорала, и он не построен на event sourcing, а просто поддерживает кеширование промежуточных результатов пайплайна. Поэтому у меня пока сложилось впечатление, что Perfect гораздо ближе по замыслу к Airflow
Да, есть Child Workflow
Тут довольно тонкий момент. Некоторые изменения — например, изменение продолжительности таймера, или изменение аргументов вызова Activity — не приводят к недетерминизму (вот здесь подробнее). Кроме того, мы вольны менять код activity вообще в любой момент, на них требования детерминизма не распространяются
Тут возможны разные варианты действий в зависимости от конкретной ситуации. Если воркфлоу паникует и не может пройти какой-то шаг, то здесь просто поможет релиз исправленного кода воркфлоу. Если workflow завис в бесконечном ожидании, то после выкатки новой версии кода можно его reset-нуть, и бизнес-логика будет выполняться заново (вместе со всеми activity) с того места, на который reset-нули. В принципе в большинстве случаев reset должен помочь — даже есть воркфлоу пошёл неправильно и уже закончился, мы всё равно сможем его reset-нуть.
По сути своей reset — это terminate исходного воркфлоу и копирование какой-то части истории в новый, который и продолжит выполняться
Всё восстановится в той же самой точке, потому что в истории событий в БД хранится вся необходимая информация, все остальные компоненты, в общем, stateless. Так, например, можно спокойно остановить сервер, обновить его, и запустить заново, единственным эффектом будет задержка выполнения действий на время этой операции
Стоило хотя бы указать, что всё это позаимствовано из Голдратта... И куда лучше описано в оригинале, чем в корявом пересказе в «методичке»
Безопаснее это на уровне железки сделать. Дублирование экранов, на втором настраиваешь зум. С точки зрения софта система чиста, разве что два монитора в режиме повторения. Но вряд ли это будет подозрительно
А можно было бы здесь, собственно, отображаемый пользователю адрес почты (
strong.text-almost-black) сделать заблокированным инпутом с особым оформлением (чтобы просто выглядело как текст)? Тогда, кажется, и дублирование не понадобится.Другое дело, что я часто встречаю формы из двух экранов — на первом только логин, на втором только пароль. Вот тут без скрытого поля уже очевидно никак
Не смог быстро найти инструкцию ручного развёртывания сервера на своём VPS. Такая есть? Не могу себе позволить вводить реквизиты от рутового доступа куда-то, кроме ssh-клиента
Интересное! Хочется теперь прочитать «полную версию», с реальными данными и интересными медицинскими фактами
Оригинальные терминалы в маке тоже подтормаживали. У меня даже закрадывались мысли, что тормоза там специально, чтобы снизить нагрузку на кухню, ибо тормозило именно тогда, когда много заказов — впрочем, плохая оптимизация будет выглядеть так же
Какие фичи есть в платформе из того, что нет в bupaR?
У нас на подъезде был именно такой классический «Сезам», абонентское устройство ровно как на фото. Установили его где-то между 1998 и 2000. Помню, что пластмассовые ключи были дешевле в заказе, но ломались в кармане очень просто, поэтому довольно быстро все сделали металлические.
Главная проблема у нашего была в том, что у него очень быстро стали мутными окошки для цифр, да и сами цифры с дисков стёрлись. Поэтому набирать их приходилось наощупь по оставшимся видимыми цифрам. И заодно привычка — сбрасывать цифры после того, как набрал свою квартиру, на всякий случай