# 구글의 'tachometer'를 사용해 Discourse의 JS 성능 변화를 측정하기

**URL:** https://meta.discourse.org/t/using-googles-tachometer-to-measure-js-performance-changes-in-discourse/281158
**Category:** Developer Guides
**Tags:** code
**Created:** [10월 5, 2023, 1:57오후 UTC](https://meta.discourse.org/t/using-googles-tachometer-to-measure-js-performance-changes-in-discourse/281158 "2023-10-05T13:57:29Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![Discourse](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/discourse/32/148734_2.png) [@Discourse](https://meta.discourse.org/u/Discourse)
#### Post date: [10월 5, 2023, 1:57오후 UTC](https://meta.discourse.org/t/using-googles-tachometer-to-measure-js-performance-changes-in-discourse/281158/1 "2023-10-05T13:57:29Z")

</div>

Discourse의 코어/플러그인/테마에서 클라이언트 사이드 작업을 수행할 때 성능 영향을 고려하는 것이 중요합니다. Google의 ‘Tachometer’ 프로젝트는 통계적으로 엄밀한 벤치마킹 도구를 제공하며, 이를 통해 변경 사항의 영향을 결정적으로 측정할 수 있습니다.

> **[GitHub - google/tachometer: Statistically rigorous benchmark runner for the...](https://github.com/google/tachometer)**
>
> Statistically rigorous benchmark runner for the web

기본적으로 이 도구는 URL 목록을 가져와 ‘라운드 로빈’ 방식으로 로드합니다. 각 페이지 로드에 대해 성능 측정을 수행합니다. 수백/수천 번의 반복 후 비교 테이블을 생성합니다.

이 ‘라운드 로빈’ 방식의 장점은 외부 요인이 측정에 미치는 영향을 줄이는 데 도움이 된다는 것입니다.

## 1단계: `performance.measure()` 추가

여기서 사용되는 접근 방식은 테스트 대상에 따라 달라집니다. 하지만 근본적으로: Tachometer가 읽을 수 있도록 `performance.measure()` 값을 도입해야 합니다.

Discourse가 부팅되고 렌더링되는 데 걸리는 시간을 측정하려면 내장된 “discourse-init-to-paint” 측정을 사용할 수 있습니다. 그 외의 경우, 자체 `performance.measure`를 도입하여 사용할 수 있습니다.

브라우저 개발자 도구의 성능 탭을 사용하여 정상 작동하는지 확인할 수 있습니다:

 ![SCR-20240529-rlhj](https://global.discourse-cdn.com/meta/original/4X/c/8/c/c8c2c8280eb16bf88a2041b68bf45af1ef81b6d8.png)

사용자 상호작용(예: 메뉴 열기)이 필요한 활동을 측정하려는 경우, 페이지가 로드된 후 1초 후에 버튼을 클릭하도록 초기화자에 다음과 같은 코드를 추가하여 이를 달성할 수 있습니다:

```js
setTimeout(() => document.querySelector(".my-button").click(), 1000);

```

## 2단계: 테스트할 URL 식별

먼저, Ember 에셋을 프로덕션 모드에서 빌드하고 있는지 확인하세요. 이는 서버를 `EMBER_ENV=production`으로 시작하여 달성할 수 있습니다.

두 가지 다른 URL을 얻기 위한 두 가지 주요 접근 방식이 있습니다:

변경 사항이 sufficiently 작아 쉽게 기능 플래그로 처리할 수 있다면, **URL 쿼리 매개변수** 를 기반으로 토글하는 로직을 추가할 수 있습니다. 그러면 두 URL은 다음과 같을 수 있습니다.

```plaintext
http://localhost:3000?flag=before
http://localhost:3000?flag=after

```

변경 사항이 너무 크다면, Discourse를 두 번째 디렉터리로 복제하고 **두 번째 rails 복사본** 을 시작할 수 있습니다.

```sh
EMBER_ENV=production UNICORN_PORT=3001 bin/dev

```

그리고 두 URL은 다음과 같습니다.

```plaintext
http://localhost:3000
http://localhost:3001

```

이 접근 방식을 사용하는 경우, 이 가이드의 1단계에서 도입한 성능 텔레메트리가 앱의 두 복사본 모두에 있는지 확인하세요.

## 3단계: Tachometer 구성

다음은 각 대상에서 300개의 샘플을 가져오는 제 `bench.json` 파일입니다:

```json
{
  "timeout": 5,
  "sampleSize": 300,
  "benchmarks": [
    {
      "measurement": {
        "mode": "performance",
        "entryName": "discourse-init-to-paint"
      },
      "expand": [
        {
          "url": "http://localhost:3000",
          "name": "before"
        },
        {
          "url": "http://localhost:3001",
          "name": "after"
        }
      ]
    }
  ]
}

```

## 4단계: 벤치마크 실행

노이즈를 줄이기 위해 워크스테이션에서 관련 없는 활동을 중지한 다음, 다음과 같은 명령으로 벤치마크를 시작하세요:

```sh
npx tachometer@latest --config ./bench.json

```

완료되면 before/after 성능 비교를 볼 수 있습니다.

 ![image](https://global.discourse-cdn.com/meta/original/4X/5/4/a/54ace74ad2a9a1fae3e339aeef572c39814b03e1.png)

## 주의사항

이러한 실험과 마찬가지로 한계를 고려할 가치가 있습니다. 예를 들어:

- 개발 워크스테이션의 성능 차이는 다른 브라우저/디바이스에 직접적으로 매핑되지 않을 수 있습니다.

- Ember-CLI 프록시를 통한 Discourse의 부팅 프로세스는 프로덕션 환경과 정확히 동일하지 않습니다. 구조적 변경(예: 프레임워크 업데이트)을 할 때 이는 중요할 수 있습니다.

- 성능은 종종 애플리케이션 상태(예: 렌더링되는 토픽 수)에 따라 달라지므로, 결과가 다른 환경에서 정확히 재현되지 않을 수 있습니다.

* * *

이 문서는 버전 관리됩니다 - 변경 사항을 [github](https://github.com/discourse/discourse/blob/main/docs/developer-guides/docs/03-code-internals/08-js-performance.md)에서 제안하세요.