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