💡 Инструкция: Выберите один ответ из пяти. Время — 85 минут. У каждого задания ровно один правильный вариант. Фрагменты рассчитаны на Ruby 4.0.6; задания Rails — на Rails 8.1.3. После завершения откроются общий процент, 6 тематических результатов и разбор всех ответов.
Вопрос 1 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Профилирование»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Профилирование Копировать
# Проследите выполнение и выберите точный результат.
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
result = Report.call(input)
elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
p [result.class, elapsed]
Ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи. Это объясняется тем, что оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти. Это объясняется тем, что оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка. Это объясняется тем, что кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка. Это объясняется тем, что оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка. Это объясняется тем, что GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Вопрос 4 из 30
Не запуская пример, выберите точный итог для блока «Кэширование». В правильном ответе вторая часть действительно объясняет или проверяет первую.
Ruby Ruby — Кэширование Копировать
# Проследите выполнение и выберите точный результат.
key = ['user-card', user.cache_key_with_version, locale]
card = Rails.cache.fetch(key, expires_in: 10.minutes) do
UserCard.build(user, locale: locale)
end
Ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи. Механизм результата таков: оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка. Механизм результата таков: кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи. Механизм результата таков: GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи. Механизм результата таков: кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
`filter_map` строит одну итоговую коллекцию вместо отдельных массивов select и map. Механизм результата таков: кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Вопрос 5 из 30
Разберите выражения по порядку. Как завершится фрагмент из раздела «Границы применимости»? Верный вариант не содержит частично правильной подмены причины или следствия.
Ruby Ruby — Границы применимости Копировать
# Проследите выполнение и выберите точный результат.
require 'set'
allowed = ids.to_set
selected = records.select { |record| allowed.include?(record.id) }
p selected.length
Замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти. Наблюдение согласуется с тем, что кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти. Наблюдение согласуется с тем, что микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти. Наблюдение согласуется с тем, что GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка. Наблюдение согласуется с тем, что микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Массив `cache` после принудительного GC по-прежнему удерживает все 1000 строк; сборщик освобождает только недостижимые объекты. Наблюдение согласуется с тем, что микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Вопрос 6 из 30
Проследите выполнение фрагмента. Какой результат верен для темы «Сопровождение проекта»? Правильным считается только полностью согласованное утверждение.
Ruby Ruby — Сопровождение проекта Копировать
# Проследите выполнение и выберите точный результат.
queries = SqlCounter.capture do
get '/dashboard'
end
raise "too many queries: #{queries}" if queries > 8
Тест фиксирует верхнюю границу числа SQL-запросов для страницы, не привязываясь к абсолютным миллисекундам машины разработчика. Этот вывод опирается на правило: каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма.
Замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти. Этот вывод опирается на правило: производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Тест фиксирует верхнюю границу числа SQL-запросов для страницы, не привязываясь к абсолютным миллисекундам машины разработчика. Этот вывод опирается на правило: микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Массив `cache` после принудительного GC по-прежнему удерживает все 1000 строк; сборщик освобождает только недостижимые объекты. Этот вывод опирается на правило: производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Тест фиксирует верхнюю границу числа SQL-запросов для страницы, не привязываясь к абсолютным миллисекундам машины разработчика. Этот вывод опирается на правило: производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Вопрос 7 из 30
Что может сломаться при переносе этого решения «Профилирование» в рабочую систему? Нужен вариант без логического разрыва между первой и второй частью.
Ruby Ruby — Профилирование Копировать
# Обычный запуск проходит. Найдите скрытый риск.
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
result = Report.call(input)
elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
p [result.class, elapsed]
Benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место. Причина — GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место. Причина — оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа. Причина — оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место. Причина — кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины. Причина — оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы.
Вопрос 8 из 30
Какое скрытое условие делает фрагмент «Аллокации» хрупким? Проверьте обе половины ответа: частично верный вариант остаётся неверным.
Ruby Ruby — Аллокации Копировать
# Обычный запуск проходит. Найдите скрытый риск.
values = (1..10_000)
result = values.filter_map do |n|
n * 2 if n.even?
end
p result.length
Жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных. Этот риск связан с тем, что каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма.
Мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия. Этот риск связан с тем, что микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия. Этот риск связан с тем, что каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма.
Мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия. Этот риск связан с тем, что производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место. Этот риск связан с тем, что каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма.
Вопрос 9 из 30
Какое допущение делает этот код по теме «Сборка мусора» ненадёжным? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Сборка мусора Копировать
# Обычный запуск проходит. Найдите скрытый риск.
cache = []
1_000.times { cache << 'x' * 1_000 }
before = cache.length
GC.start
after = cache.length
p [before, after, cache.sum(&:bytesize)]
Вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины. Уязвимое место возникает потому, что микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа. Уязвимое место возникает потому, что GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины. Уязвимое место возникает потому, что кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место. Уязвимое место возникает потому, что GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины. Уязвимое место возникает потому, что GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Вопрос 10 из 30
Что в реализации по теме «Кэширование» требует исправления прежде всего? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Кэширование Копировать
# Обычный запуск проходит. Найдите скрытый риск.
key = ['user-card', user.cache_key_with_version, locale]
card = Rails.cache.fetch(key, expires_in: 10.minutes) do
UserCard.build(user, locale: locale)
end
Ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа. К такому сбою приводит правило: GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе.
Ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа. К такому сбою приводит правило: микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Использование Set для десятка элементов в редком пути может усложнить код без измеримого выигрыша. К такому сбою приводит правило: кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа. К такому сбою приводит правило: кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины. К такому сбою приводит правило: кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией.
Вопрос 12 из 30
Что может сломаться при переносе этого решения «Сопровождение проекта» в рабочую систему? Оценивайте ответ целиком: обе части утверждения должны быть точными.
Ruby Ruby — Сопровождение проекта Копировать
# Обычный запуск проходит. Найдите скрытый риск.
queries = SqlCounter.capture do
get '/dashboard'
end
raise "too many queries: #{queries}" if queries > 8
Мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия. Проблема возникает из-за того, что производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных. Проблема возникает из-за того, что микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов.
Benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место. Проблема возникает из-за того, что производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных. Проблема возникает из-за того, что каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма.
Жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных. Проблема возникает из-за того, что производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора.
Вопрос 13 из 30
Какое общее правило связывает результат и риск в разделе «Профилирование»? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе. Поэтому измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка.
Оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы. Поэтому замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти.
Оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы. Поэтому ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи.
Оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы. Поэтому измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка.
Кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией. Поэтому измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка.
Вопрос 14 из 30
Как сформулировать правило блока «Аллокации» без лишних обещаний? Не выбирайте ответ по одному точному фрагменту: вся формулировка должна выдерживать проверку.
Микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов. Из этого следует, что `filter_map` строит одну итоговую коллекцию вместо отдельных массивов select и map.
Каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма. Из этого следует, что ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи.
Производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора. Из этого следует, что `filter_map` строит одну итоговую коллекцию вместо отдельных массивов select и map.
Каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма. Из этого следует, что измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка.
Каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма. Из этого следует, что `filter_map` строит одну итоговую коллекцию вместо отдельных массивов select и map.
Вопрос 16 из 30
Какое правило остаётся верным, даже если вход и порядок вызовов изменятся, в теме «Кэширование»? Верный вариант не содержит частично правильной подмены причины или следствия.
Кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией. Именно поэтому ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи.
Кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией. Именно поэтому `filter_map` строит одну итоговую коллекцию вместо отдельных массивов select и map.
Оптимизацию начинают с профиля полного сценария; wall time, CPU time, SQL и ожидание сети отвечают на разные вопросы. Именно поэтому ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи.
Кэш корректен только при точном ключе, сроке и стратегии инвалидирования; ускорение устаревшего ответа не является оптимизацией. Именно поэтому измерение monotonic clock не ломается от коррекции системного времени и показывает длительность участка.
GC освобождает недостижимые Ruby-объекты, но не исправляет удержание ссылок и не гарантирует немедленный возврат RSS операционной системе. Именно поэтому ключ включает id и `cache_key_with_version`, поэтому меняется после обновления записи.
Вопрос 18 из 30
Какой принцип темы «Сопровождение проекта» переносится на другие примеры того же типа? Одного совпавшего вывода недостаточно — проверьте также вторую часть ответа.
Производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора. Практическое следствие правила: массив `cache` после принудительного GC по-прежнему удерживает все 1000 строк; сборщик освобождает только недостижимые объекты.
Производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора. Практическое следствие правила: тест фиксирует верхнюю границу числа SQL-запросов для страницы, не привязываясь к абсолютным миллисекундам машины разработчика.
Микрооптимизация применима только при сохранении контракта и заметной доле времени; асимптотика и I/O обычно важнее выбора близких методов. Практическое следствие правила: тест фиксирует верхнюю границу числа SQL-запросов для страницы, не привязываясь к абсолютным миллисекундам машины разработчика.
Производительность — сопровождаемый контракт: бюджет, контрольный сценарий и регрессия должны быть видны в тестах/метриках, а не жить в памяти автора. Практическое следствие правила: замена повторного линейного поиска на Set меняет сложность большого цикла, но требует дополнительной памяти.
Каждая новая String, Array, Hash и обёртка увеличивает давление на GC; устранение промежуточных коллекций может снизить память без изменения алгоритма. Практическое следствие правила: тест фиксирует верхнюю границу числа SQL-запросов для страницы, не привязываясь к абсолютным миллисекундам машины разработчика.
Вопрос 19 из 30
Как исправить реализацию «Профилирование» без новой скрытой зависимости? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Профилирование Копировать
# Выберите изменение, которое исправляет причину.
start = Process.clock_gettime(Process::CLOCK_MONOTONIC)
result = Report.call(input)
elapsed = Process.clock_gettime(Process::CLOCK_MONOTONIC) - start
p [result.class, elapsed]
Сначала получить flame graph/профиль запросов и аллокаций, затем менять только подтверждённый горячий путь с контрольным тестом. Так закрывается риск: вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины.
Сначала получить flame graph/профиль запросов и аллокаций, затем менять только подтверждённый горячий путь с контрольным тестом. Так закрывается риск: мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия.
Измерять `GC.stat`/allocation profiler и сохранять ясную семантику владения; оптимизировать только крупный повторяющийся путь. Так закрывается риск: benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место.
Оценивать объём данных, частоту и память; сохранять простой вариант для малого набора, если профиль не показывает проблему. Так закрывается риск: benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место.
Сначала получить flame graph/профиль запросов и аллокаций, затем менять только подтверждённый горячий путь с контрольным тестом. Так закрывается риск: benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место.
Вопрос 20 из 30
Какой подход сохраняет намерение кода и устраняет дефект в теме «Аллокации»? Сопоставьте не только итог, но и правило, риск или проверку, которые с ним связаны.
Ruby Ruby — Аллокации Копировать
# Выберите изменение, которое исправляет причину.
values = (1..10_000)
result = values.filter_map do |n|
n * 2 if n.even?
end
p result.length
Закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом. Это изменение устраняет проблему: мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия.
Измерять `GC.stat`/allocation profiler и сохранять ясную семантику владения; оптимизировать только крупный повторяющийся путь. Это изменение устраняет проблему: benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место.
Измерять `GC.stat`/allocation profiler и сохранять ясную семантику владения; оптимизировать только крупный повторяющийся путь. Это изменение устраняет проблему: жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных.
Сначала получить flame graph/профиль запросов и аллокаций, затем менять только подтверждённый горячий путь с контрольным тестом. Это изменение устраняет проблему: мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия.
Измерять `GC.stat`/allocation profiler и сохранять ясную семантику владения; оптимизировать только крупный повторяющийся путь. Это изменение устраняет проблему: мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия.
Вопрос 21 из 30
Какое инженерное решение лучше всего соответствует механизму «Сборка мусора»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Сборка мусора Копировать
# Выберите изменение, которое исправляет причину.
cache = []
1_000.times { cache << 'x' * 1_000 }
before = cache.length
GC.start
after = cache.length
p [before, after, cache.sum(&:bytesize)]
Искать путь удержания через heap dump/ObjectSpace и ограничивать жизненный цикл кэшей, подписок и глобальных реестров. Такая правка нужна из-за риска: ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа.
Включать все влияющие параметры, ограничивать размер/TTL и измерять hit rate вместе с долей устаревших результатов. Такая правка нужна из-за риска: вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины.
Искать путь удержания через heap dump/ObjectSpace и ограничивать жизненный цикл кэшей, подписок и глобальных реестров. Такая правка нужна из-за риска: benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место.
Искать путь удержания через heap dump/ObjectSpace и ограничивать жизненный цикл кэшей, подписок и глобальных реестров. Такая правка нужна из-за риска: вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины.
Закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом. Такая правка нужна из-за риска: вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины.
Вопрос 22 из 30
Какой рефакторинг переводит правило «Кэширование» из договорённости в проверяемый контракт? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Кэширование Копировать
# Выберите изменение, которое исправляет причину.
key = ['user-card', user.cache_key_with_version, locale]
card = Rails.cache.fetch(key, expires_in: 10.minutes) do
UserCard.build(user, locale: locale)
end
Закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом. Решение адресует следующий дефект: ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа.
Включать все влияющие параметры, ограничивать размер/TTL и измерять hit rate вместе с долей устаревших результатов. Решение адресует следующий дефект: вызов `GC.start` в каждом запросе маскирует удержание ссылок и добавляет паузы вместо устранения причины.
Искать путь удержания через heap dump/ObjectSpace и ограничивать жизненный цикл кэшей, подписок и глобальных реестров. Решение адресует следующий дефект: ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа.
Включать все влияющие параметры, ограничивать размер/TTL и измерять hit rate вместе с долей устаревших результатов. Решение адресует следующий дефект: использование Set для десятка элементов в редком пути может усложнить код без измеримого выигрыша.
Включать все влияющие параметры, ограничивать размер/TTL и измерять hit rate вместе с долей устаревших результатов. Решение адресует следующий дефект: ключ только по id продолжает возвращать старое представление после изменения объекта или прав доступа.
Вопрос 24 из 30
Какой вариант правки выдержит граничный сценарий темы «Сопровождение проекта»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Ruby Ruby — Сопровождение проекта Копировать
# Выберите изменение, которое исправляет причину.
queries = SqlCounter.capture do
get '/dashboard'
end
raise "too many queries: #{queries}" if queries > 8
Измерять `GC.stat`/allocation profiler и сохранять ясную семантику владения; оптимизировать только крупный повторяющийся путь. После изменения не должен сохраняться риск: жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных.
Закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом. После изменения не должен сохраняться риск: benchmark одного маленького вызова без разогрева и реальных данных измеряет шум, JIT/GC и не то узкое место.
Закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом. После изменения не должен сохраняться риск: мутация ради уменьшения аллокаций может разрушить общий объект и дать более дорогую ошибку, чем исходная экономия.
Закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом. После изменения не должен сохраняться риск: жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных.
Оценивать объём данных, частоту и память; сохранять простой вариант для малого набора, если профиль не показывает проблему. После изменения не должен сохраняться риск: жёсткий тест на время в CI нестабилен и одновременно не ловит рост запросов, который проявится только на больших данных.
Вопрос 29 из 30
Какой тест даст новую информацию о надёжности решения «Границы применимости»? Смотрите на всю причинную связку, а не только на знакомую формулировку.
Проверить стоимость построения Set: если поиск выполняется один раз, преобразование может быть дороже массива. На этой границе проверяется мера: закреплять структурные показатели в тестах, а реальные задержки и память — в непрерывных нагрузочных измерениях с бюджетом.
Проверить блок, который создаёт строки или Hash на каждом элементе: одна коллекция не означает мало аллокаций. На этой границе проверяется мера: оценивать объём данных, частоту и память; сохранять простой вариант для малого набора, если профиль не показывает проблему.
Проверить stampede при истечении популярного ключа: множество процессов может одновременно пересчитать значение. На этой границе проверяется мера: оценивать объём данных, частоту и память; сохранять простой вариант для малого набора, если профиль не показывает проблему.
Проверить стоимость построения Set: если поиск выполняется один раз, преобразование может быть дороже массива. На этой границе проверяется мера: измерять `GC.stat`/allocation profiler и сохранять ясную семантику владения; оптимизировать только крупный повторяющийся путь.
Проверить стоимость построения Set: если поиск выполняется один раз, преобразование может быть дороже массива. На этой границе проверяется мера: оценивать объём данных, частоту и память; сохранять простой вариант для малого набора, если профиль не показывает проблему.