의미있는 벤치 마크를 작성하기 위해 어떤 조언을 할 수 있습니까?

Question

저는 조직의 여러 팀이 사용하는 프레임 워크를 개발했습니다. 이 프레임 워크 위에 개발 된 이러한 "모듈"은 상당히 다르게 행동 할 수 있지만 일부는 다른 것보다 더 많은 자원을 소비합니다. 그들은 모두 입력으로 데이터를 받고, 분석 및/또는 변환하고, 더 전송합니다.

우리는 새로운 하드웨어를 구매할 계획이었고 상사는 우리가 얻은 다양한 제안을 비교하기 위해 모듈을 기반으로 벤치 마크를 정의하고 구현하도록 요청했습니다.

내 아이디어는 잘 선택된 많은 데이터를 입력으로 순차적으로 순차적으로 시작하는 것입니다.

조언이 있습니까? 이 간단한 절차에 대한 언급이 있습니까?

Answer 1

당신의 질문은 꽤 넓기 때문에 불행히도 내 대답은 그다지 구체적이지 않을 것입니다.

첫째, 벤치마킹은 어렵습니다. 의미 있고 반복적 인 높은 신뢰도를 생성하는 데 필요한 노력을 과소 평가하지 마십시오.

둘째, 성능 목표는 무엇입니까? 처리량인가 (초당 트랜잭션 또는 운영)입니까? 대기 시간입니까 (트랜잭션을 실행하는 데 시간이 걸린 시간)? 평균 성능에 관심이 있습니까? 최악의 성능에 관심이 있습니까? 당신은 절대 최악의 경우에 관심이 있습니까? 아니면 90%, 95% 또는 다른 백분위 수가 적절한 성능을 얻는 것을 걱정하십니까?

목표에 따라 해당 목표를 측정하기 위해 벤치 마크를 설계해야합니다. 따라서 처리량에 관심이 있으시면 메시지 / 트랜잭션 / 입력을 규정 된 속도로 시스템에 보내고 시스템이 유지되는지 확인하려고합니다.

대기 시간에 관심이있는 경우 메시지 / 트랜잭션 / 입력을 보내고 각각을 처리하는 데 걸리는 시간을 측정합니다.

최악의 사례 성능에 관심이 있다면 "현실적"(또는 시스템 설계가 지원 해야하는 모든 것에 대해 고려할 때까지 시스템에 부하를 추가하게됩니다.)

둘째, 이러한 모듈이 CPU 바운드, I/O 바운드가 될지 여부는 여러 CPU/코어 등을 활용할 수있는 경우 다른 하드웨어 솔루션을 평가하려고 할 때 애플리케이션 혜택을받을 수 있습니다. 더 많은 I/O 하위 시스템과 수많은 CPU에서.

셋째, 가장 좋은 벤치 마크 (및 가장 어려운)는 현실적인 부하를 시스템에 넣는 것입니다. 즉, 프로덕션 환경에서 데이터를 기록 하고이 데이터를 통해 새로운 하드웨어 솔루션을 넣습니다. 이 작업을 완료하는 것보다 더 어렵습니다. 종종 시스템에 모든 종류의 측정 포인트를 추가하여 기존 시스템을 수정하여 레코드/재생 기능을 추가하고 수정하는 방법을 확인하는 방법을 확인하는 것을 의미합니다. 다른 속도로 실행되는 재생 및 테스트를 위해 현실적인 (예 : 생산과 유사한) 환경을 얻는다.

Answer 2

가장 의미있는 벤치 마크는 일상적인 사용에 따라 코드의 수행 방식을 측정하는 것입니다. 그것은 분명히 가장 현실적인 숫자를 제공 할 것입니다.

여러 실제 데이터 세트를 선택하고 조직이 매일 사용하는 것과 동일한 프로세스를 통해 배치하십시오. 추가 신용을 원하시면 프레임 워크를 사용하는 사람들과 대화하고 "최고의 사례", "정상"및 "최악의"데이터를 제공하도록 요청하십시오. 개인 정보 보호 문제가있는 경우 데이터를 익명화하지만 성능에 영향을 줄 수있는 것을 변경하지 마십시오.

프레임 워크가 아닌 두 개의 하드웨어 세트를 벤치마킹하고 비교하고 있음을 기억하십시오. 모든 소프트웨어를 블랙 박스로 취급하고 하드웨어 성능을 단순히 측정하십시오.

마지막으로, 데이터 세트를 저장하고이를 사용하여 소프트웨어에 대한 이후 변경 사항을 비슷하게 평가하는 것을 고려하십시오.

Answer 3

시스템이 여러 클라이언트를 동시에 호출 할 수 있어야하는 경우 벤치 마크가이를 반영해야합니다. 일부 전화는 함께 잘 작동하지 않습니다. 예를 들어, 25 개의 스레드가 동시에 동시에 동일한 비트를 게시하면 서버 엔드에 잠금이 발생하여 결과가 왜곡 될 수 있습니다.

너트와 볼트의 관점에서, 나는 Perl과 그것의 벤치 마크 모듈 내가 관심있는 정보를 수집하기 위해.

Answer 4

다른 하드웨어를 비교하는 경우 거래 당 비용을 측정하면 성능을 위해 하드웨어의 트레이드 오프를 잘 비교할 수 있습니다. 하나의 구성은 최고의 성능을 제공 할 수 있지만 비용이 너무 많습니다. 저렴한 구성은 적절한 성능을 제공 할 수 있습니다.

하중의 "최악의 경우"또는 "피크 시간"을 모방하는 것이 중요합니다. "일반적인"볼륨으로 테스트하는 것이 중요합니다. 좋은 서버 활용을 얻는 것은 균형 잡힌 행동입니다. 비용이 많이 들지 않아 필요한 성능을 제공합니다.

하드웨어 구성에 대한 테스트는 빠르게 비싸집니다. 또 다른 실행 가능한 옵션은 먼저 구성을 측정 한 다음 모델을 사용하여 가상 시스템에서 해당 동작을 시뮬레이션하는 것입니다.

Answer 5

가능하다면 일부 운영 사용자 (또는 프로세스)가 프레임 워크를 사용하여 실제 시스템의 클론을 사용하는 것을 기록하십시오. 그것은 당신에게 가장 현실적인 데이터를 제공합니다. 고려해야 할 사항 :

1. 어떤 기능이 가장 자주 사용됩니까?
2. 얼마나 많은 데이터가 전송됩니까?
3. 아무것도 가정하지 마십시오. "빠르거나 느리게 될 것"이라고 생각한다면 내기하지 마십시오. 10 건 중 9 건에서는 틀 렸습니다.

1+2의 상위 10 개를 만들고 그로부터 작업하십시오.

즉, 이전 하드웨어를 새로운 하드웨어로 교체하면 첫 번째 세트를 구입 한 이후로 통과 한 매년 약 10% 더 빠른 실행을 기대할 수 있습니다 (시스템이 꽤 동일하다면).

전문 시스템이있는 경우 숫자는 완전히 다를 수 있지만 일반적으로 새 하드웨어는 크게 변경되지 않습니다. 예를 들어, 데이터베이스에 유용한 색인을 추가하면 쿼리 런타임이 2 시간에서 2 초로 줄어들 수 있습니다. 하드웨어는 결코 당신에게 그것을 줄 수 없습니다.

Answer 6

내가 알 수 있듯이 벤치마킹 소프트웨어와 관련하여 두 가지 종류의 벤치 마크가 있습니다. 먼저, MicroBenchmarks는 코드 조각을 분리하여 또는 시스템이 좁게 정의 된 워크로드를 처리하는 방법을 평가하려고 할 때. Java로 작성된 두 가지 정렬 알고리즘을 비교하십시오. 두 개의 웹 브라우저를 비교하여 각각 DOM 조작 작업을 얼마나 빨리 수행 할 수 있는지 비교하십시오. 둘째, 현실적인 워크로드에서 소프트웨어 시스템을 평가하려고 할 때 시스템 벤치 마크가 있습니다 (이름을 올렸습니다). Google Compute Engine 및 Amazon AWS에서 실행되는 파이썬 기반 백엔드를 비교하십시오.

Java 등을 다룰 때 VM은 현실적인 성능을 제공하기 전에 워밍업해야한다는 점을 명심하십시오. 당신이 시간을 측정한다면 time 명령, JVM 시작 시간이 포함됩니다. 거의 항상 시작 시간을 무시하거나 별도로 추적하려고합니다.

마이크로 렌칭

첫 번째 실행 중에 CPU 캐시는 필요한 데이터로 채워지고 있습니다. 디스크 캐시도 마찬가지입니다. 이후 몇 번의 실행 중에 VM은 계속 워밍업을합니다. 즉, JIT는 컴파일에 도움이되는 것을 컴파일합니다. 이 실행을 무시하고 나중에 측정을 시작하려고합니다.

많은 측정을하고 일부 통계를 계산하십시오. 평균, 중앙값, 표준 편차는 차트를 플로팅합니다. 그것을보고 그것이 얼마나 많이 변하는 지 확인하십시오. 결과에 영향을 줄 수있는 것은 VM의 GC 일시 정지, CPU의 주파수 스케일링, 다른 프로세스는 일부 배경 작업 (바이러스 스캔과 같은)을 시작할 수 있으며 OS는 다른 CPU 코어에서 프로세스 이동을 결정할 수 있습니다. numa가 있습니다 아키텍처, 결과는 더욱 표시 될 것입니다.

MicroBenchmarks의 경우이 모든 것이 문제입니다. 시작하기 전에 할 수있는 프로세스를 처치하십시오. 당신을 위해 일부를 할 수있는 벤치마킹 라이브러리를 사용하십시오. 처럼 https://github.com/google/caliper 그리고 그런 것과 같은.

시스템 벤치마킹

현실적인 워크로드에서 시스템을 벤치마킹하는 경우, 이러한 세부 사항은 실제로 관심이 없으며 귀하의 문제는 현실적인 워크로드가 무엇인지, 생성하는 방법 및 수집 할 데이터를 알기위한 "문제"입니다. 생산 시스템을 도구하고 데이터를 수집 할 수 있다면 항상 최선입니다. 최종 사용자 특성을 측정하고 (웹 페이지 렌더링이 얼마나되었는지)를 측정하고 있기 때문에 일반적으로 그렇게 할 수 있으며 I/O 바운드이므로 코드 수집 데이터가 시스템 속도를 늦추지 않습니다. (페이지를 네트워크를 통해 사용자에게 배송해야하므로 프로세스에 몇 개의 숫자를 기록해도 중요하지 않습니다).

프로파일 링과 벤치마킹의 차이점을 염두에 두십시오. 벤치마킹은 무언가를하는 데 절대적인 시간을 줄 수 있으며, 프로파일 링은 필요한 모든 일에 비해 무언가를하는 데 소요되는 시간을 제공합니다. 프로파일 러가 크게 계측 된 프로그램을 실행하기 때문입니다 (일반적인 기술은 수백 ms마다 세워지고 스택 추적을 저장하는 것입니다). 계측은 모든 것을 크게 느리게 만듭니다.