measureUserAgentSpecificMemory()로 웹페이지의 총 메모리 사용량을 모니터링합니다.

프로덕션에서 웹페이지의 메모리 사용량을 측정하여 회귀를 감지하는 방법을 알아보세요.

Brendan Kenny

Ulan Degenbaev

브라우저는 웹페이지의 메모리를 자동으로 관리합니다. 웹페이지에서 객체를 만들 때마다 브라우저는 객체를 저장하기 위해 '내부적으로' 메모리 청크를 할당합니다. 메모리는 유한한 리소스이므로 브라우저는 가비지 컬렉션을 실행하여 더 이상 필요하지 않은 객체를 감지하고 기본 메모리 청크를 해제합니다.

하지만 감지가 완벽하지는 않으며 앨런 튜링의 정지 문제로 인해 완벽한 감지는 불가능한 작업임이 증명되었습니다. 따라서 브라우저는 '객체가 필요함'이라는 개념을 '객체에 도달할 수 있음'이라는 개념으로 근사합니다. 웹페이지가 변수와 도달 가능한 다른 객체의 필드를 통해 객체에 도달할 수 없는 경우 브라우저는 객체를 안전하게 회수할 수 있습니다. 이 두 개념의 차이로 인해 다음 예와 같이 메모리 누수가 발생합니다.

const object = {a: new Array(1000), b: new Array(2000)};
setInterval(() => console.log(object.a), 1000);

여기서 더 큰 배열 b는 더 이상 필요하지 않지만 브라우저는 콜백의 object.b를 통해 여전히 도달할 수 있으므로 회수하지 않습니다. 따라서 더 큰 배열의 메모리가 누수됩니다.

이 연구에서 볼 수 있듯이 웹에서는 메모리 누수가 일반적입니다. 이벤트 리스너 등록 취소를 잊거나, 실수로 iframe에서 객체를 캡처하거나, 작업자를 닫지 않거나, 배열에 객체를 누적하는 등의 방법으로 쉽게 도입할 수 있습니다. 웹페이지에 메모리 누수가 있으면 시간이 지남에 따라 메모리 사용량이 증가하고 웹페이지가 사용자에게 느리고 부풀어 보입니다.

이 문제를 해결하는 첫 번째 단계는 측정하는 것입니다. 새로운 performance.measureUserAgentSpecificMemory() API를 사용하면 개발자가 프로덕션에서 웹페이지의 메모리 사용량을 측정하여 로컬 테스트를 통해 누수되는 메모리 누수를 감지할 수 있습니다.

performance.measureUserAgentSpecificMemory()는 기존 performance.memory API와 어떻게 다른가요?

기존의 비표준 performance.memory API에 익숙하다면 새 API가 기존 API와 어떻게 다른지 궁금할 수 있습니다. 주요 차이점은 이전 API는 JavaScript 힙의 크기를 반환하는 반면 새 API는 웹페이지에서 사용하는 메모리를 추정한다는 것입니다. 이 차이는 Chrome이 여러 웹페이지 (또는 동일한 웹페이지의 여러 인스턴스)와 동일한 힙을 공유할 때 중요해집니다. 이러한 경우 이전 API의 결과가 임의로 벗어날 수 있습니다. 이전 API는 '힙'과 같은 구현별 용어로 정의되므로 표준화는 불가능합니다.

또 다른 차이점은 새 API가 가비지 컬렉션 중에 메모리 측정을 실행한다는 것입니다. 이렇게 하면 결과의 노이즈가 줄어들지만 결과가 생성될 때까지 시간이 걸릴 수 있습니다. 다른 브라우저에서는 가비지 컬렉션에 의존하지 않고 새 API를 구현할 수 있습니다.

권장 사용 사례

웹페이지의 메모리 사용량은 이벤트, 사용자 작업, 가비지 컬렉션의 타이밍에 따라 다릅니다. 이러한 이유로 메모리 측정 API는 프로덕션의 메모리 사용량 데이터를 집계하기 위한 것입니다. 개별 호출의 결과는 덜 유용합니다. 사용 사례 예:

• 웹페이지의 새 버전을 출시하는 동안 회귀 감지하여 새로운 메모리 누수를 포착합니다.
• 새 기능을 A/B 테스트하여 메모리 영향을 평가하고 메모리 누수를 감지합니다.
• 메모리 사용량을 세션 시간과 상호 연결하여 메모리 누수의 존재 여부를 확인합니다.
• 메모리 사용량을 사용자 측정항목과 상호 연결하여 메모리 사용량의 전반적인 영향을 파악합니다.

브라우저 호환성

현재 API는 Chrome 89부터 Chromium 기반 브라우저에서만 지원됩니다. 브라우저마다 메모리에 객체를 표시하는 방법과 메모리 사용량을 추정하는 방법이 다르기 때문에 API의 결과는 구현에 크게 좌우됩니다. 브라우저는 적절한 회계가 너무 비싸거나 불가능한 경우 회계에서 일부 메모리 영역을 제외할 수 있습니다. 따라서 브라우저 간에 결과를 비교할 수 없습니다. 동일한 브라우저의 결과만 비교하는 것이 의미가 있습니다.

performance.measureUserAgentSpecificMemory() 사용

기능 감지

실행 환경이 교차 출처 정보 누출을 방지하기 위한 보안 요구사항을 충족하지 않는 경우 performance.measureUserAgentSpecificMemory 함수를 사용할 수 없거나 SecurityError와 함께 실패할 수 있습니다. 웹페이지가 COOP+COEP 헤더를 설정하여 활성화할 수 있는 교차 출처 격리에 의존합니다.

런타임에 지원을 감지할 수 있습니다.

if (!window.crossOriginIsolated) {
  console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
} else if (!performance.measureUserAgentSpecificMemory) {
  console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
} else {
  let result;
  try {
    result = await performance.measureUserAgentSpecificMemory();
  } catch (error) {
    if (error instanceof DOMException && error.name === 'SecurityError') {
      console.log('The context is not secure.');
    } else {
      throw error;
    }
  }
  console.log(result);
}

로컬 테스트

Chrome은 가비지 컬렉션 중에 메모리 측정을 실행합니다. 즉, API는 결과 프로미스를 즉시 확인하지 않고 대신 다음 가비지 컬렉션을 기다립니다.

API를 호출하면 현재 20초로 설정된 시간 제한 후에 가비지 컬렉션이 강제로 실행되지만 더 빨리 발생할 수도 있습니다. --enable-blink-features='ForceEagerMeasureMemory' 명령줄 플래그로 Chrome을 시작하면 시간 제한이 0으로 줄어들며 로컬 디버깅 및 테스트에 유용합니다.

예

API의 권장 사용법은 전체 웹페이지의 메모리 사용량을 샘플링하고 집계 및 분석을 위해 결과를 서버로 전송하는 전역 메모리 모니터를 정의하는 것입니다. 가장 간단한 방법은 예를 들어 M분마다 주기적으로 샘플링하는 것입니다. 하지만 메모리 피크가 샘플 사이에 발생할 수 있으므로 데이터에 편향이 발생합니다.

다음 예에서는 샘플이 언제든지 발생할 가능성이 동일하도록 보장하는 포아송 프로세스를 사용하여 편향되지 않은 메모리 측정을 실행하는 방법을 보여줍니다(데모, 소스).

먼저 임의 간격으로 setTimeout()을 사용하여 다음 메모리 측정을 예약하는 함수를 정의합니다.

function scheduleMeasurement() {
  // Check measurement API is available.
  if (!window.crossOriginIsolated) {
    console.log('performance.measureUserAgentSpecificMemory() is only available in cross-origin-isolated pages');
    console.log('See https://web.dev/coop-coep/ to learn more')
    return;
  }
  if (!performance.measureUserAgentSpecificMemory) {
    console.log('performance.measureUserAgentSpecificMemory() is not available in this browser');
    return;
  }
  const interval = measurementInterval();
  console.log(`Running next memory measurement in ${Math.round(interval / 1000)} seconds`);
  setTimeout(performMeasurement, interval);
}

measurementInterval() 함수는 평균적으로 5분마다 한 번의 측정이 이루어지도록 밀리초 단위의 임의 간격을 계산합니다. 함수 뒤에 있는 수학에 관심이 있다면 지수 분포를 참고하세요.

function measurementInterval() {
  const MEAN_INTERVAL_IN_MS = 5 * 60 * 1000;
  return -Math.log(Math.random()) * MEAN_INTERVAL_IN_MS;
}

마지막으로 비동기 performMeasurement() 함수는 API를 호출하고 결과를 기록하며 다음 측정을 예약합니다.

async function performMeasurement() {
  // 1. Invoke performance.measureUserAgentSpecificMemory().
  let result;
  try {
    result = await performance.measureUserAgentSpecificMemory();
  } catch (error) {
    if (error instanceof DOMException && error.name === 'SecurityError') {
      console.log('The context is not secure.');
      return;
    }
    // Rethrow other errors.
    throw error;
  }
  // 2. Record the result.
  console.log('Memory usage:', result);
  // 3. Schedule the next measurement.
  scheduleMeasurement();
}

마지막으로 측정을 시작합니다.

// Start measurements.
scheduleMeasurement();

결과는 다음과 같을 수 있습니다.

// Console output:
{
  bytes: 60_100_000,
  breakdown: [
    {
      bytes: 40_000_000,
      attribution: [{
        url: 'https://example.com/',
        scope: 'Window',
      }],
      types: ['JavaScript']
    },

    {
      bytes: 20_000_000,
      attribution: [{
          url: 'https://example.com/iframe',
          container: {
            id: 'iframe-id-attribute',
            src: '/iframe',
          },
          scope: 'Window',
      }],
      types: ['JavaScript']
    },

    {
      bytes: 100_000,
      attribution: [],
      types: ['DOM']
    },
  ],
}

총 메모리 사용량 추정치는 bytes 필드에 반환됩니다. 이 값은 구현에 크게 좌우되며 브라우저 간에 비교할 수 없습니다. 동일한 브라우저의 버전 간에도 변경될 수 있습니다. 이 값에는 현재 프로세스의 모든 iframe, 관련 창, 웹 작업자의 JavaScript 및 DOM 메모리가 포함됩니다.

breakdown 목록은 사용된 메모리에 관한 추가 정보를 제공합니다. 각 항목은 메모리의 일부를 설명하고 URL로 식별된 창, iframe, 작업자 집합에 속성을 할당합니다. types 필드에는 메모리와 연결된 구현별 메모리 유형이 나열됩니다.

모든 목록을 일반적인 방식으로 처리하고 특정 브라우저를 기반으로 가정을 하드코딩하지 않는 것이 중요합니다. 예를 들어 일부 브라우저는 빈 breakdown 또는 빈 attribution을 반환할 수 있습니다. 다른 브라우저는 이러한 항목 중 어느 항목이 메모리를 소유하는지 구분할 수 없음을 나타내는 여러 항목을 attribution에 반환할 수 있습니다.

의견

웹 성능 커뮤니티 그룹과 Chrome팀은 에 관한 의견과 경험을 듣고 싶습니다. performance.measureUserAgentSpecificMemory()

API 설계에 관해 알려주세요

API가 예상대로 작동하지 않는 부분이 있나요? 또는 아이디어를 구현하는 데 필요한 속성이 누락되었나요? performance.measureUserAgentSpecificMemory() GitHub 저장소에서 사양 문제를 제출하거나 기존 문제에 의견을 추가하세요.

구현 문제 신고

Chrome의 구현에서 버그를 발견했나요? 또는 구현이 사양과 다른가요? new.crbug.com에서 버그를 제출하세요. 최대한 많은 세부정보를 포함하고, 버그를 재현하기 위한 간단한 안내를 제공하고, 구성요소를 Blink>PerformanceAPIs로 설정해야 합니다.

지원 표시

performance.measureUserAgentSpecificMemory()를 사용할 계획인가요? 공개 지원은 Chrome팀이 기능의 우선순위를 지정하는 데 도움이 되며 다른 브라우저 공급업체에 이러한 기능을 지원하는 것이 얼마나 중요한지 보여줍니다. @ChromiumDev 에 트윗을 보내 어디에서 어떻게 사용하고 있는지 알려주세요.

유용한 링크

• 설명 동영상
• 데모 | 데모 소스
• 버그 추적
• ChromeStatus.com 항목
• Origin Trial API 이후 변경사항
• 종료된 Origin Trial

감사의 말씀

API 설계 검토를 위해 Domenic Denicola, Yoav Weiss, Mathias Bynens에게, Chrome의 코드 검토를 위해 Dominik Inführ, Hannes Payer, Kentaro Hara, Michael Lippautz에게 진심으로 감사드립니다. 또한 API를 크게 개선한 유용한 사용자 의견을 제공해 주신 Per Parker, Philipp Weis, Olga Belomestnykh, Matthew Bolohan, Neil Mckay에게도 감사드립니다.