코드 수준 성능 테스트

개발
1

최근 ActivityPub 플러그인의 성능을 살펴보고 있으며, 이러한 프로젝트의 목적을 위해 성능을 안정적으로 테스트하고 증명하는 가장 좋은 방법에 대해 고민하고 있습니다. 몇 가지 초기 배경 정보를 공유합니다:

  • 이 플러그인은 여러 주체가 관여하는 오픈소스 프로젝트입니다(즉, 플러그인을 소유한 Discourse와 현재 이를 구축 중인 Pavilion).

  • 각 주체마다 내부적으로 다른 성능 테스트 도구/시스템을 사용할 수 있습니다.

  • 다자간 오픈소스 프로젝트는 어떤 것이(또는 이 경우 성능이) 안정적으로 작동하는지 테스트하고 증명하는 공통적으로 사용 가능한 방법에서 이점을 얻습니다.

  • Discourse(찬사할 만하게) 성능을 중시합니다.

  • 현재 제가 아는 한, Discourse에서 서버 측 성능을 테스트/증명하는 공통적으로 사용 가능한 유일한 방법은 track_sql_queries이며, 이는 일반적으로(단독으로만은 아니지만) 요청 테스트에서 사용됩니다.

  • 쿼리 개수는 성능의 지표 중 하나이지만 유일한 지표는 아닙니다(일부 쿼리는 다른 쿼리보다 더 무겁습니다).

track_sql_queries 사용의 최근 예시는 다음과 같습니다.

이 분야에 익숙하시다면 아마도 다음과 같은 것을 아실 것입니다.

경험칙으로, 단위 테스트는 속도가 필요하고 성능 테스트는 시간이 필요합니다.

(이 좋은 설명 글의 인용)

이는 겉으로 볼 때, (쿼리 카운팅을 넘어선) 성능 테스트를 rspec(또는 유사한) 스위트에 통합하는 것이 다소 어렵게 만들 수 있습니다. 그럼에도 불구하고 일부는 시도를 합니다.

Discourse 생태계에 더 공통적으로 사용 가능한 성능 테스트 및 성능 증명을 추가하기 위해 다른 사람들이 가진 실용적인 방법, 제안 또는 아이디어가 무엇인지 궁금합니다. 또는 제가 여기에 언급하지 않은 방법이나 접근 방식이 있는지요. 저는 "실용적인"과 "공통적으로 사용 가능한"이라는 단어에 중점을 두고 싶습니다.

생각되는 것 중 하나는 스펙에서 MiniProfiler를 사용할 수 있다는 것입니다. 즉, Rack::MiniProfiler.profile_singleton_method와 같은 것입니다. 하지만 저는 그것을 시도해 본 적도 없고, 그것이 좋은 아이디어인지도 모릅니다.

2

일반적으로 스펙(spec)에서 성능 테스트를 피하는 것을 권장합니다.

N+1 문제를 모니터링하려는 몇 가지 예제가 있지만, 모두 꽤 취약한 경향이 있습니다.

해결책이 명확하지 않은 매우 어려운 문제이며, 모든 솔루션에는 타협이 따르기 때문에 일반적으로 이를 피하고 이 유형의 문제를 프로덕션 환경에서 모니터링합니다.