Performance тесты

При оценке производительности сцен на базе CesiumJS основное внимание уделяется нескольким ключевым параметрам: частоте кадров, времени отрисовки кадра, нагрузке на CPU/GPU, объёму используемой памяти и количеству сетевых запросов к тайлам.

FPS (frames per second) отражает стабильность визуализации. Значения ниже 30 FPS в интерактивной сцене обычно указывают на перегрузку рендера или чрезмерную геометрию.

Frame time (ms) более точен, чем FPS, так как показывает реальную стоимость одного кадра. В CesiumJS целевой диапазон для интерактивных сцен — 16–33 мс.

GPU time позволяет выявить узкие места в шейдерах, постобработке и отрисовке 3D Tiles.

CPU time чаще всего связан с:

  • подготовкой сцены (culling, traversal дерева тайлов)
  • обработкой сущностей (Entities API)
  • декодированием геометрии

Tile request rate отражает сетевую активность и качество LOD-стратегии.

Инструменты измерения производительности внутри CesiumJS

CesiumJS предоставляет встроенные механизмы диагностики сцены, позволяющие проводить базовый анализ без внешних профилировщиков.

Scene debug-индикаторы

  • отображение FPS:
scene.debugShowFramesPerSecond = true;
  • визуализация тайлов:
scene.globe.tileLoadProgressDisplay = new Cesium.TileLoadProgressDisplay();
  • отладка отрисовки:
viewer.scene.debugShowCommands = true;

Performance Display

Встроенный overlay позволяет отслеживать:

  • количество draw calls
  • число загруженных тайлов
  • время рендера

Использование requestRenderMode для оптимизации тестов

Одним из ключевых режимов оптимизации является requestRenderMode, который отключает непрерывный рендеринг и активирует отрисовку только при изменениях сцены.

const viewer = new Cesium.Viewer("cesiumContainer", {
    requestRenderMode: true,
    maximumRenderTimeChange: Infinity
});

Этот режим особенно важен при тестировании, так как позволяет:

  • фиксировать затраты на единичные изменения сцены
  • исключать «фоновые» кадры
  • точно измерять влияние операций (добавление сущностей, загрузка тайлов)

Методология нагрузочного тестирования сцены

Тестирование производительности CesiumJS обычно строится вокруг сценарного подхода, где создаются повторяемые нагрузки.

Типовые сценарии:

  • массовая загрузка 3D Tiles
  • рендеринг миллионов Entity
  • динамическая анимация объектов
  • переключение уровней детализации
  • работа с высокочастотными обновлениями координат

Каждый сценарий измеряется по фиксированным метрикам:

  • средний FPS
  • 95-й перцентиль frame time
  • время до первого кадра (TTFP)
  • время полной загрузки сцены

Профилирование CPU и GPU

CPU-профилирование

Используется стандартный инструментарий браузера:

  • Chrome DevTools Performance tab
  • Sampling CPU profiler
  • Flame chart анализа вызовов CesiumJS runtime

Особое внимание уделяется:

  • Scene.render
  • PrimitiveCollection.update
  • TileManager.processTileLoadQueue

GPU-профилирование

GPU анализ включает:

  • количество draw calls
  • заполнение пикселей (fill rate)
  • стоимость шейдеров материалов

Инструменты:

  • WebGL Inspector
  • Spector.js
  • встроенные WebGL debug extensions

Тестирование загрузки 3D Tiles

3D Tiles — один из самых ресурсоёмких компонентов экосистемы CesiumJS.

Ключевые параметры:

  • глубина дерева тайлов
  • количество активных узлов
  • стратегия culling
  • геометрическая сложность тайлов

Оптимизация проверяется через сценарии:

  • постепенное приближение камеры к массиву данных
  • резкое перемещение между регионами (stress LOD switching)
  • отключение/включение tileset в runtime

Метрики:

  • tile load latency
  • number of rejected tiles (due to culling)
  • memory footprint per tileset

Автоматизированные performance-тесты

Автотестирование производительности строится поверх headless-окружений.

Типовая схема:

  • запуск CesiumJS сцены в headless Chrome
  • выполнение сценариев через Puppeteer
  • сбор performance metrics через window.performance

Пример измерения времени рендера:

const start = performance.now();

viewer.scene.render();

const end = performance.now();
console.log("Render time:", end - start);

Для стабильности тестов используются:

  • фиксированная позиция камеры
  • отключённые анимации
  • предзагруженные тайлы

Регрессионные тесты производительности

Регрессия выявляется через сравнение базовой версии и текущей сборки.

Методика:

  • фиксируется baseline FPS и frame time
  • каждая новая сборка прогоняется через одинаковые сценарии
  • отклонения выше заданного порога фиксируются как деградация

Критичные метрики:

  • +10–15% роста frame time
  • увеличение draw calls без изменения сцены
  • рост памяти более чем на 20% в длительном прогоне

Управление памятью и утечки

В долгоживущих сценах CesiumJS ключевым фактором становится контроль памяти.

Основные источники роста:

  • неосвобождённые Primitive/Entity
  • кэшированные текстуры
  • tileset с неочищенными ресурсами

Диагностика:

performance.memory.usedJSHeapSize

и инструменты Chrome Heap Snapshot.

Типовые проверки:

  • многократное добавление/удаление объектов
  • циклическая смена tilesets
  • длительная анимация камеры

Оптимизация тестируемых сцен

При проведении performance-тестов часто применяется набор стандартных оптимизаций:

  • включение frustum culling
  • снижение screenSpaceError у 3D Tiles
  • использование batching для геометрии
  • отключение лишних post-processing эффектов
  • ограничение максимального числа одновременно загруженных тайлов

Метрики сетевой подсистемы

Сетевой слой CesiumJS напрямую влияет на производительность сцен с большими данными.

Измеряются:

  • количество HTTP-запросов
  • средняя задержка загрузки тайлов
  • размер загруженных ресурсов

Инструменты:

  • Network panel DevTools
  • Cesium Resource loader logging

Критический показатель — burst-загрузка тайлов при быстром перемещении камеры.

Сценарии стресс-тестирования

Стресс-тесты направлены на выявление предельной устойчивости рендера.

Типовые нагрузки:

  • 10–50 млн полигонов в сцене
  • непрерывное перемещение камеры с высокой скоростью
  • одновременная работа нескольких tilesets
  • динамическое добавление/удаление сущностей

Поведение системы оценивается по:

  • стабильности FPS без провалов
  • отсутствию фризов GC
  • времени восстановления после нагрузки

Сравнительный анализ сборок

При разработке крупных приложений на CesiumJS применяется сравнительный анализ:

  • разные версии движка
  • разные конфигурации рендера
  • альтернативные стратегии загрузки тайлов

Результаты фиксируются в виде:

  • таблиц frame time
  • графиков FPS по времени
  • распределения задержек рендера

Это позволяет выявлять деградации на уровне отдельных изменений кода движка или приложения.

Оглавление