Discourse 코어/플러그인/테마에서 클라이언트 측 작업을 수행할 때 성능 영향을 고려하는 것이 중요합니다. Google의 ‘Tachometer’ 프로젝트는 통계적으로 엄밀한 벤치마킹 도구를 제공하며, 이를 사용하여 변경 사항의 효과를 확실히 측정할 수 있습니다.
기본적으로 이 도구는 URL 목록을 받아 ‘라운드 로빈’ 방식으로 로드합니다. 각 페이지 로드에 대해 몇 가지 성능 측정을 수행합니다. 수백~수천 번의 반복 후, 비교 테이블을 생성합니다.
이 ‘라운드 로빈’ 방식의 장점은 외부 요인이 측정에 미치는 영향을 줄이는 데 도움이 된다는 것입니다.
1단계: performance.measure() 추가
여기서 사용되는 접근 방식은 무엇을 테스트하느냐에 따라 달라집니다. 하지만 근본적으로: Tachometer가 읽을 수 있도록 performance.measure() 값을 도입해야 합니다.
Discourse가 부팅되고 렌더링되는 데 걸리는 시간을 렌더링하려면 내장된 “discourse-init-to-paint” 측정을 사용할 수 있습니다. 그 외의 경우, 자체 performance.measure를 도입하여 사용할 수 있습니다.
브라우저 개발자 도구의 성능 탭을 사용하여 정상 작동하는지 확인할 수 있습니다:
사용자 상호작용이 필요한 활동을 측정하려는 경우(예: 메뉴 열기), 페이지가 로드된 후 1초 후 버튼을 클릭하도록 초기화기에 다음과 같은 코드를 추가하여 이를 달성할 수 있습니다:
setTimeout(() => document.querySelector(".my-button").click(), 1000);
2단계: 테스트할 URL 식별
먼저, 프로덕션 모드에서 Ember 에셋을 빌드하고 있는지 확인하십시오. 이는 EMBER_ENV=production으로 서버를 시작하여 달성할 수 있습니다.
두 개의 서로 다른 URL을 얻기 위한 두 가지 주요 접근 방식이 있습니다:
변경 사항이 sufficiently 작아 쉽게 기능 플래그를 설정할 수 있다면, URL 쿼리 파라미터를 기반으로 토글하는 로직을 추가할 수 있습니다. 그러면 두 URL은 다음과 같을 수 있습니다.
http://localhost:3000?flag=before
http://localhost:3000?flag=after
변경 사항이 너무 크다면, git worktree를 생성하고 다른 포트에서 rails의 두 번째 복사본을 실행할 수 있습니다:
git worktree add ../discourse-after my-branch
cd ../discourse-after
bundle install
pnpm install
EMBER_ENV=production UNICORN_PORT=3001 bin/dev
두 복사본은 동일한 데이터베이스와 Redis를 공유하므로, 한 분기에 있는 마이그레이션이 다른 분기에 없는지 확인하십시오.
그리고 두 URL은 다음과 같을 것입니다.
http://localhost:3000
http://localhost:3001
이 접근 방식을 사용한다면, 이 가이드의 1단계에서 도입한 성능 텔레메트리가 앱의 두 복사본 모두에 있는지 확인하십시오.
3단계: Tachometer 구성
다음은 각 대상에 대해 300개의 샘플을 가져오는 제 bench.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단계: 벤치마크 실행
노이즈를 줄이기 위해 워크스테이션에서 관련 없는 활동을 중지한 다음, 다음과 같은 명령으로 벤치마크를 시작하십시오:
pnpx tachometer --config ./bench.json
완료되면 변경 전/후 성능 비교를 볼 수 있습니다.
주의 사항
이러한 실험과 마찬가지로 한계를 고려하는 것이 가치가 있습니다. 예를 들어:
-
개발 워크스테이션의 성능 차이는 다른 브라우저/디바이스로 직접 매핑되지 않을 수 있습니다.
-
개발 모드에서 Discourse의 부팅 과정은 프로덕션과 정확히 동일하지 않습니다. 구조적 변경(예: 프레임워크 업데이트)을 할 때 이는 중요할 수 있습니다.
-
성능은 종종 애플리케이션 상태(예: 렌더링되는 토픽 수)에 따라 달라지므로, 다른 환경에서 결과가 정확히 재현되지 않을 수 있습니다.
이 문서는 버전 관리됩니다 - github에서 변경 사항을 제안하십시오.
