Как подготовить Rails-код к параллельной работе через Ractor
Глубокий разбор адаптации Rails-кода к Ractor. У каждого Ractor своя блокировка виртуальной машины, что позволяет исполнять Ruby-код параллельно. Цена этого: запрет делить изменяемые объекты между Ractor.
В карте такого рефакторинга разобраны четыре узла:
Глубокая заморозка объектов через
удаление мемоизации или перенос вычисления в
Read-Copy-Update для настроек: скопировать значение, изменить, заморозить и заменить;
новый API для публичных изменяемых значений без поломки обратной совместимости.
Небольшие приложения команда уже запускает на Ractor, но крупные Rails-приложения с множеством гемов пока остаются целью. Читать Ruby-разработчикам, которые хотят начать аудит с изменяемых констант, ленивых вычислений и настраиваемых API.
Глубокий разбор адаптации Rails-кода к Ractor. У каждого Ractor своя блокировка виртуальной машины, что позволяет исполнять Ruby-код параллельно. Цена этого: запрет делить изменяемые объекты между Ractor.
В карте такого рефакторинга разобраны четыре узла:
Глубокая заморозка объектов через
Ractor.make_shareable;удаление мемоизации или перенос вычисления в
initialize либо freeze;Read-Copy-Update для настроек: скопировать значение, изменить, заморозить и заменить;
новый API для публичных изменяемых значений без поломки обратной совместимости.
Небольшие приложения команда уже запускает на Ractor, но крупные Rails-приложения с множеством гемов пока остаются целью. Читать Ruby-разработчикам, которые хотят начать аудит с изменяемых констант, ленивых вычислений и настраиваемых API.
Как изолировать медленного WebSocket-клиента
При блокирующей отправке клиент, который не успевает читать события, задерживает общий цикл: остальные тоже ждут. Обстоятельный разбор обратного давления показывает, как локализовать перегрузку.
Каждому клиенту выделяют отдельную ограниченную очередь, а события кладут в неё без ожидания. Если очередь заполнена, новое событие отбрасывают только для этого клиента, учитывают потерю и переходят к следующему. В архитектуре NomadCrew буфер вмещает 256 событий.
Отбрасывание оставляет пробел в данных. Поэтому клиенту нужен путь повторной синхронизации: заново запросить текущее состояние. Так он восстановит актуальную картину, но не историю пропущенных событий.
Для WebSocket-хаба проверьте три вещи: очереди ограничены, пропуски видны в метриках, клиент может перечитать текущее состояние после отставания.
При блокирующей отправке клиент, который не успевает читать события, задерживает общий цикл: остальные тоже ждут. Обстоятельный разбор обратного давления показывает, как локализовать перегрузку.
Каждому клиенту выделяют отдельную ограниченную очередь, а события кладут в неё без ожидания. Если очередь заполнена, новое событие отбрасывают только для этого клиента, учитывают потерю и переходят к следующему. В архитектуре NomadCrew буфер вмещает 256 событий.
Отбрасывание оставляет пробел в данных. Поэтому клиенту нужен путь повторной синхронизации: заново запросить текущее состояние. Так он восстановит актуальную картину, но не историю пропущенных событий.
Для WebSocket-хаба проверьте три вещи: очереди ограничены, пропуски видны в метриках, клиент может перечитать текущее состояние после отставания.
Автоматизация обслуживания ScyllaDB в Discord: устройство задач и сценариев
Инженерный разбор замены хрупких скриптов системой управления кластерами. Команда Discord обслуживает сотни узлов ScyllaDB и перед обновлениями создаёт временные копии кластеров, которые получают те же чтения и записи, что и рабочие базы.
В разборе Scylla Control Plane показаны задачи на Rust и сценарии в YAML. Перед выполнением задачи проверяются условия безопасности. Повторный запуск должен давать тот же результат, что и однократный: это требование делает повторы при сбоях безопасными. Ограничения параллелизма позволяют перезапускать узлы по одной зоне размещения, не более двух одновременно внутри неё.
Для инженеров инфраструктуры здесь есть ориентир: порядок шагов, проверки состояния и допустимый параллелизм задаются явно, а не остаются в голове оператора.
#архитектура #разборы
Инженерный разбор замены хрупких скриптов системой управления кластерами. Команда Discord обслуживает сотни узлов ScyllaDB и перед обновлениями создаёт временные копии кластеров, которые получают те же чтения и записи, что и рабочие базы.
В разборе Scylla Control Plane показаны задачи на Rust и сценарии в YAML. Перед выполнением задачи проверяются условия безопасности. Повторный запуск должен давать тот же результат, что и однократный: это требование делает повторы при сбоях безопасными. Ограничения параллелизма позволяют перезапускать узлы по одной зоне размещения, не более двух одновременно внутри неё.
Для инженеров инфраструктуры здесь есть ориентир: порядок шагов, проверки состояния и допустимый параллелизм задаются явно, а не остаются в голове оператора.
#архитектура #разборы
Детерминированные тесты TigerBeetle: проверки внутри реплик
Обстоятельный разбор тестирования распределённой базы с доступом к состоянию каждой реплики. Проверки через публичный API показывают поведение базы для клиента, но не охватывают все внутренние гарантии.
Симулятор запускает настоящий код базы, заменяет сеть и диски управляемыми моделями и ускоряет время. Он воспроизводит разрывы сети, повреждения дисков и падения реплик; найденный сбой можно повторить.
При фиксации каждой операции симулятор сверяет её контрольную сумму между репликами. Разбор также показывает, как проверки хранения связаны с требованием побайтового совпадения данных. В рабочей базе нарушение проверяемой гарантии останавливает реплику.
Для разработчиков распределённых систем это карта проверок за пределами API. Условие подхода: код базы должен выполняться детерминированно.
#разборы #архитектура
Обстоятельный разбор тестирования распределённой базы с доступом к состоянию каждой реплики. Проверки через публичный API показывают поведение базы для клиента, но не охватывают все внутренние гарантии.
Симулятор запускает настоящий код базы, заменяет сеть и диски управляемыми моделями и ускоряет время. Он воспроизводит разрывы сети, повреждения дисков и падения реплик; найденный сбой можно повторить.
При фиксации каждой операции симулятор сверяет её контрольную сумму между репликами. Разбор также показывает, как проверки хранения связаны с требованием побайтового совпадения данных. В рабочей базе нарушение проверяемой гарантии останавливает реплику.
Для разработчиков распределённых систем это карта проверок за пределами API. Условие подхода: код базы должен выполняться детерминированно.
#разборы #архитектура
Ускорение строковых агрегаций в DuckDB через таблицу измерений
SQL-гайд по замене повторяющихся строк числовыми ключами показывает, как сократить обработку текста при группировке. Таблица измерений хранит каждое название один раз вместе с ключом: запрос считает группы по числам и возвращает названия после агрегации.
Пример построен на 380 959 записях об остановках поездов и 537 названиях станций. Для них хватает двухбайтового USMALLINT. Ключи назначаются в алфавитном порядке, поэтому сортировка по ключу сохраняет порядок названий. LEFT JOIN сохраняет строки без станции, с NULL вместо ключа.
Для инженеров данных разобраны два варианта: сохранить ключи в основной таблице или соединять её со справочником при каждом запросе. Первый требует переписать таблицу один раз; второй оставляет обработку строк при каждом соединении.
#производительность #гайды
SQL-гайд по замене повторяющихся строк числовыми ключами показывает, как сократить обработку текста при группировке. Таблица измерений хранит каждое название один раз вместе с ключом: запрос считает группы по числам и возвращает названия после агрегации.
Пример построен на 380 959 записях об остановках поездов и 537 названиях станций. Для них хватает двухбайтового USMALLINT. Ключи назначаются в алфавитном порядке, поэтому сортировка по ключу сохраняет порядок названий. LEFT JOIN сохраняет строки без станции, с NULL вместо ключа.
Для инженеров данных разобраны два варианта: сохранить ключи в основной таблице или соединять её со справочником при каждом запросе. Первый требует переписать таблицу один раз; второй оставляет обработку строк при каждом соединении.
#производительность #гайды
Адаптивное разбиение HashJoin в Bolt: меньше повторных выгрузок на диск
При соединении таблиц через хеш-таблицу нехватка памяти вынуждает Bolt разбивать строки на разделы и писать их на диск. Если раздел снова не помещается в память, цикл повторяется: чтение, разбиение, запись.
В техническом разборе адаптивного разбиения первая нехватка памяти служит оценкой вместимости. Bolt сопоставляет число обработанных строк с общим числом строк: при 10 млн строк и вместимости около 800 тысяч фиксированных 4 разделов мало, а адаптивный выбор может дать 16 или 32.
В статье показан путь статистики строк до решения о разбиении. Число разделов только увеличивается; ширина строк влияет на точность оценки, а перекос ключей всё ещё может создавать слишком крупные разделы. Разработчикам аналитических движков здесь есть что учесть при диагностике повторных выгрузок.
#производительность #разборы
При соединении таблиц через хеш-таблицу нехватка памяти вынуждает Bolt разбивать строки на разделы и писать их на диск. Если раздел снова не помещается в память, цикл повторяется: чтение, разбиение, запись.
В техническом разборе адаптивного разбиения первая нехватка памяти служит оценкой вместимости. Bolt сопоставляет число обработанных строк с общим числом строк: при 10 млн строк и вместимости около 800 тысяч фиксированных 4 разделов мало, а адаптивный выбор может дать 16 или 32.
В статье показан путь статистики строк до решения о разбиении. Число разделов только увеличивается; ширина строк влияет на точность оценки, а перекос ключей всё ещё может создавать слишком крупные разделы. Разработчикам аналитических движков здесь есть что учесть при диагностике повторных выгрузок.
#производительность #разборы
Bolt
Adaptive Spill Partitioning: Using Runtime Row Counts to Reduce Recursive HashJoin Spill
When the build side of a HashJoin exceeds its memory budget, the hash table has to be split by hash partition and written to disk. The basic mechanism is straightforward: split build rows into partitions, read partitions back one by one, rebuild the hash…
Как StarTree проверяет релизы Apache Pinot под нагрузкой и при отказах
В инженерном разборе StarTree показывает устройство сервиса проверки релизов своей аналитической платформы на Apache Pinot. Стенд совмещает приём данных и запросы с перебалансировкой таблиц и случайными перезапусками серверов.
Сервис на FastAPI принимает задания, а Argo Workflows управляет их выполнением. Команда сохраняет структуру клиентских запросов, скрывает чувствительные имена и значения и создаёт синтетические данные. Результаты преобразования строк сравнивают на текущей и следующей версиях, чтобы выявить несовместимость до обновления.
Разбор для разработчиков распределённых систем: здесь есть многодневные проверки и сценарии одновременных операций. Успешная проверка перебалансировки сама по себе не показывает, как система выдержит её на фоне интенсивного приёма данных.
#разборы #архитектура
В инженерном разборе StarTree показывает устройство сервиса проверки релизов своей аналитической платформы на Apache Pinot. Стенд совмещает приём данных и запросы с перебалансировкой таблиц и случайными перезапусками серверов.
Сервис на FastAPI принимает задания, а Argo Workflows управляет их выполнением. Команда сохраняет структуру клиентских запросов, скрывает чувствительные имена и значения и создаёт синтетические данные. Результаты преобразования строк сравнивают на текущей и следующей версиях, чтобы выявить несовместимость до обновления.
Разбор для разработчиков распределённых систем: здесь есть многодневные проверки и сценарии одновременных операций. Успешная проверка перебалансировки сама по себе не показывает, как система выдержит её на фоне интенсивного приёма данных.
#разборы #архитектура
Бенчмарки TidesDB и RocksDB: где настройки определяют результат
Обстоятельный разбор сравнения TidesDB 10.0.0 и RocksDB 11.8.1 на двух серверах показывает, почему вместе со скоростью нужно читать условия замеров. В основе пять нагрузок, от смешанных операций до корзины покупок.
Основное сравнение использует настройки по умолчанию, но сжатие отключено у обеих баз. TidesDB отдельно хранит крупные значения; у RocksDB аналогичная возможность проверена дополнительным прогоном. Каждый замер длится 60 секунд, результат берётся как медиана трёх повторов.
На большом сервере преимущество TidesDB сокращается. Но меняется не только диск: потоки закреплены за ядрами, а база заново заполняется перед каждым замером. Инженерам производительности здесь стоит сверить методику своих тестов: различия между серверами нельзя объяснить одним накопителем.
#производительность #разборы
Обстоятельный разбор сравнения TidesDB 10.0.0 и RocksDB 11.8.1 на двух серверах показывает, почему вместе со скоростью нужно читать условия замеров. В основе пять нагрузок, от смешанных операций до корзины покупок.
Основное сравнение использует настройки по умолчанию, но сжатие отключено у обеих баз. TidesDB отдельно хранит крупные значения; у RocksDB аналогичная возможность проверена дополнительным прогоном. Каждый замер длится 60 секунд, результат берётся как медиана трёх повторов.
На большом сервере преимущество TidesDB сокращается. Но меняется не только диск: потоки закреплены за ядрами, а база заново заполняется перед каждым замером. Инженерам производительности здесь стоит сверить методику своих тестов: различия между серверами нельзя объяснить одним накопителем.
#производительность #разборы
👍1
Forwarded from Нейроканал
Showboat и Rodney помогают показать работу ИИ-агента
Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.
Эту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.
Уиллисон замечал и обход механизма: агент напрямую правит текст отчёта. Тогда записанный вывод может расходиться с реальным запуском. Содержимое демонстрации тоже требует проверки.
#ии #инструменты
Саймон Уиллисон собирает демонстрации кода с помощью двух своих инструментов. Showboat выполняет команды и записывает их вывод в документ. Rodney управляет Chrome из командной строки и делает скриншоты интерфейса.
uvx showboat --helpЭту команду автор предлагает дать агенту: в справке есть всё необходимое, чтобы тот создал документ с демонстрацией новой функции.
Уиллисон замечал и обход механизма: агент напрямую правит текст отчёта. Тогда записанный вывод может расходиться с реальным запуском. Содержимое демонстрации тоже требует проверки.
#ии #инструменты
Forwarded from Нейроканал
Вспомните последний раз, когда ИИ сделал для вас рабочий результат: код, тесты, документацию или требования. Как вы его проверяли?
Anonymous Poll
15%
Внимательно разобрал сам
37%
Проверил на практике: тесты, запуск, реальные данные
25%
И разобрал, и проверил на практике
1%
Отдал на ревью коллеге
13%
Не проверял, сразу использовал
6%
Не было такого случая или не помню
4%
Другое (напишу в комментариях)
Панель слоёв Figma: меньше вычислений и кэш с линейным расходом памяти
В инженерном разборе панели слоёв команда Figma показывает, почему отрисовки только видимых строк недостаточно: прежний код всё равно собирал данные для всех раскрытых узлов, хотя на экране обычно видны 20–30 строк.
Сбор разделили на два прохода: сначала получают порядок строк, затем вычисляют имена, значки и состояния только для видимых. Кэш учитывает зависимости между узлами, поэтому изменение ветки требует пересчёта лишь затронутых частей дерева.
Отдельный раздел посвящён памяти: вместо копий списков потомков кэш хранит общие части по ссылкам. Расход растёт линейно с числом узлов, ценой дополнительных переходов по указателям. Для разработчиков сложных списков это повод проверить и объём вычислений, и устройство кэша.
#производительность #архитектура
В инженерном разборе панели слоёв команда Figma показывает, почему отрисовки только видимых строк недостаточно: прежний код всё равно собирал данные для всех раскрытых узлов, хотя на экране обычно видны 20–30 строк.
Сбор разделили на два прохода: сначала получают порядок строк, затем вычисляют имена, значки и состояния только для видимых. Кэш учитывает зависимости между узлами, поэтому изменение ветки требует пересчёта лишь затронутых частей дерева.
Отдельный раздел посвящён памяти: вместо копий списков потомков кэш хранит общие части по ссылкам. Расход растёт линейно с числом узлов, ценой дополнительных переходов по указателям. Для разработчиков сложных списков это повод проверить и объём вычислений, и устройство кэша.
#производительность #архитектура
Мобильные тесты Shopify: строгие проверки и визуальный поиск элементов
В инженерном разборе обёртки над Appium команда Shopify показывает, как вернула тесты пользовательских сценариев в обязательные проверки изменений кода. По её данным, доля успешных запусков отдельных тестов выросла с 50% до 98%.
Каждое действие требует проверки: ожидаемое условие должно быть ложным до действия и истинным после. Вместо поиска элементов в дереве компонентов тест ищет их на снимке экрана: PaddleOCR распознаёт текст, OpenCV сопоставляет иконки с образцами. Appium по-прежнему управляет устройством.
Видео с отметками поиска и нажатий помогает разобрать сбой без повторного запуска. Новые тесты проходят многократные прогоны перед допуском к обязательным проверкам. Мобильным разработчикам стоит читать ради устройства API, которое ограничивает способы написать нестабильный тест.
#разборы
В инженерном разборе обёртки над Appium команда Shopify показывает, как вернула тесты пользовательских сценариев в обязательные проверки изменений кода. По её данным, доля успешных запусков отдельных тестов выросла с 50% до 98%.
Каждое действие требует проверки: ожидаемое условие должно быть ложным до действия и истинным после. Вместо поиска элементов в дереве компонентов тест ищет их на снимке экрана: PaddleOCR распознаёт текст, OpenCV сопоставляет иконки с образцами. Appium по-прежнему управляет устройством.
Видео с отметками поиска и нажатий помогает разобрать сбой без повторного запуска. Новые тесты проходят многократные прогоны перед допуском к обязательным проверкам. Мобильным разработчикам стоит читать ради устройства API, которое ограничивает способы написать нестабильный тест.
#разборы