# P07-B. DeathStarBench: размещение и интерференция - **Версия и дата проверки:** 1.1, 07.09.2026. - **Статус:** готово к назначению. ## Статья и исходные материалы - **Основная статья:** Yu Gan и соавт. — [An Open-Source Benchmark Suite for Microservices and Their Hardware-Software Implications for Cloud & Edge Systems](https://ygan397.github.io/publication/2019.asplos.deathstarbench/2019.asplos.deathstarbench.pdf). ASPLOS 2019. - **Кратко о статье:** DeathStarBench — открытый набор сквозных приложений, представляющих типичные графы облачных и edge-микросервисов. Поведение приложения зависит от отдельных сервисов, их взаимодействия с аппаратными ресурсами и программным стеком. В этом проекте исследуется, как размещение сервисов и фоновая конкуренция меняют сквозную хвостовую задержку. - **Почему результат актуален:** набор нагрузок продолжает использоваться как открытый стенд для исследований микросервисов. Конкретные зависимости отдельных приложений могут устаревать, поэтому перед проектом фиксируется собираемая версия. Выводы ограничиваются исследуемым графом сервисов и не распространяются на весь современный облачный стек. - **Артефакты и данные:** [delimitrou/DeathStarBench](https://github.com/delimitrou/DeathStarBench) под Apache-2.0, с несколькими приложениями, контейнерами и генераторами нагрузки. Зафиксированная основная ревизия: `delimitrou/DeathStarBench@6ecb09706140` (Apache-2.0). - **Что уже предоставляет артефакт:** Готовы приложения, контейнеры, нагрузки и средства наблюдения DeathStarBench. Их разрешено использовать как основу стенда; готовые конфигурации размещения служат исходными вариантами. ## Обязательный результат - **Проверяемый вопрос или утверждение:** Совместное размещение и фоновая конкуренция меняют хвостовую задержку сквозного запроса в зависимости от структуры графа; равномерное распределение CPU не всегда даёт лучший результат. - **Технический результат:** Развернуть один сокращённый сквозной граф DeathStarBench, добавить управляемое размещение контейнеров, фоновую CPU- и memory-нагрузку и трассировку критического пути. - **Обязательное приращение команды:** Реализовать предусмотренное управляемое размещение, CPU- и memory-интерференцию и сравнение изолированного, случайного и учитывающего граф размещения. Собрать трассы критического пути и объяснить измеренные изменения при двух уровнях нагрузки и двух видах интерференции. - **Эксперимент:** Сравнить изолированное и случайное размещение как baselines с размещением, учитывающим граф, при двух уровнях нагрузки и двух видах интерференции. Выполнить не менее трёх серий; измерить throughput, p50/p95/p99, длины очередей, загрузку ресурсов и вклад сервисов в критический путь. - **Границы выводов:** эффект размещения и интерференции проверяется на одном сокращённом графе и доступных локальных узлах; результат не оценивает качество полноценного кластерного планировщика и переносимость политики на производственную топологию. - **Ресурсный профиль:** расширенно локально, Docker, CPU, желательно 16–32 ГБ памяти. Запасной вариант — оставить один опубликованный сервис и уменьшить число реплик, сохранив сквозной граф вызовов. ## Содержательные направления - развёртывание и управление размещением. - генератор нагрузки, интерференция и наблюдаемость. - политика размещения, повторные серии и причинный анализ. ## Возможное продолжение Добавить сетевую интерференцию, динамическое перемещение одного сервиса, ограничение мощности либо проверить перенос политики на второй граф вызовов.