RPC 성능을 벤치마크하는 방법

작성자: Alchemy

마지막 업데이트: 2026년 6월 30일7분 읽기

벤치마크 수치는 인용하기는 쉽지만 잘못 해석하기도 쉽습니다. RPC 성능의 경우 특히 그렇습니다. 하나의 레이턴시 차트 뒤에는 여러 질문이 숨어 있을 수 있습니다. 요청이 어디서 시작되었는지, 어떤 메서드가 실행되었는지, 어떤 페이로드가 전송되었는지, 무엇을 성공으로 간주했는지, 실패는 어떻게 처리했는지, 그리고 테스트가 RPC 호출 하나를 측정한 것인지 아니면 전체 애플리케이션 워크플로를 측정한 것인지 등입니다.

저희는 이러한 세부 사항을 드러내기 위해 공개 EVM read 벤치마크를 만들었습니다. 목표는 통제되고 재현 가능한 테스트 환경에서 프로바이더들이 어떻게 비교되는지 보여주는 것입니다.

이 벤치마크는 선택된 체인, 지역, 시간대에서 일반적인 EVM JSON-RPC read 메서드에 대해 프로바이더들이 어떻게 비교되는지에 답합니다.

이는 메서드 단위의 인프라 벤치마크입니다. 즉, 각 메서드, 체인, 프로바이더, 지역마다 별도로 실행되는 통제된 방법론입니다. 이는 지갑 포트폴리오를 불러오거나, 스왑을 준비하거나, 여러 호출에 걸쳐 트랜잭션 상태를 폴링하는 것과 같은 전체 애플리케이션 워크플로가 아니라, 개별 RPC 요청을 측정합니다. 이 차이는 중요합니다. 메서드 단위 결과는 개발자가 프로바이더 동작을 비교하는 데 도움이 되지만, 어떤 프로덕션 앱의 완전한 모델은 아닙니다.

Alchemy의 공개 EVM read 벤치마크란?

Alchemy의 공개 EVM read 벤치마크는 RPC 프로바이더들이 구성된 EVM JSON-RPC read 요청에 어떻게 응답하는지 측정하는 통제된 테스트입니다. 성공 응답 레이턴시(평균, p50, p95), 성공률, 실패 요청 수를 캡처하며, 프로바이더, 체인, 메서드, 지역, 시간대별로 그룹화합니다.

레이턴시는 성공한 응답에 대해서만 계산합니다. 실패한 시도와 타임아웃은 성공률과 실패 요청 수를 통해 별도로 추적합니다. 이를 통해 벤치마크가 두 지표 중 하나만 따로 다루지 않고, 속도와 신뢰성 모두에 초점을 맞추도록 합니다.

정의 및 측정 규칙

이 게시글의 나머지 부분이 근거로 삼는 정의, 설정, 규칙입니다. 각 행은 아래 섹션에서 자세히 설명합니다.

Concept or rule	What it means
What the benchmark measures	Successful-response latency (average, p50, p95), success rate, and failed-request counts for configured EVM JSON-RPC read requests. Results are grouped by provider, chain, method, region, and time window.
JSON-RPC	The standard message format apps use to ask blockchain nodes for data. In plain English, the app sends a structured request like "get this wallet balance" or "return this transaction receipt," and the node sends back a structured answer.
Method-level benchmark	A test of one configured RPC request with one payload, such as eth_getBalance, eth_getBlockByNumber, eth_getLogs, or eth_getTransactionReceipt.
What is not measured	Full app workflows, write transactions, customer-specific traffic mixes, first-request connection setup, block freshness, every chain, every provider, and every possible payload shape.
Request origin	The benchmark runs from controlled AWS ECS regions: US East, US West, EU Central, and AP Southeast. This describes benchmark traffic only, not all Alchemy production traffic.
Test frequency	Common public EVM read methods run approximately every 10 seconds.
Success criteria	A request succeeds only if it returns before the 8-second timeout, returns HTTP 2xx, parses as JSON, and does not contain a JSON-RPC error object.
Latency calculation	Latency is measured only for successful responses. It is runner-side wall-clock time for the measured JSON-RPC POST request and response over a warmed, reused HTTP connection.
Timeout handling	Timeouts count as failures. They are not inserted into latency calculations as 8,000 ms responses.
Retries	None. The benchmark makes one attempt. If that attempt fails, the failure is counted.
Latency with success rate	Latency shows how quickly valid responses return. Success rate shows how often they return successfully at all.

벤치마크는 무엇을 다루는가?

이 벤치마크는 Ethereum, Optimism, Arbitrum, Base, World Chain 메인넷을 다루며, 공개 프로바이더 목록에는 Alchemy, dRPC, Infura, QuickNode가 포함됩니다. 널리 사용되는 EVM 메인넷과 개발자가 가장 자주 평가하는 RPC 프로바이더들을 다루기 위해 이들을 선택했으며, 향후 목록을 확장할 여지를 두었습니다. 특정 메서드에 대해 모든 프로바이더는 동일하게 구성된 JSON-RPC 요청을 받습니다.

각 테스트는 US East, US West, EU Central, AP Southeast의 통제된 AWS ECS 지역에서 실행합니다. 같은 지역 안에서는 모든 프로바이더를 동일한 러너 위치에서 테스트하는데, 네트워크 거리가 레이턴시를 바꿀 수 있기 때문입니다. 만약 한 프로바이더는 버지니아에서, 다른 프로바이더는 싱가포르에서 테스트한다면, 그 결과는 프로바이더 성능만큼이나 지리적 요인에 대해서도 말해주게 됩니다.

각 결과는 다음 기준으로 그룹화됩니다.

프로바이더
체인
메서드
지역
추적 시간대(trailing time window)

벤치마크는 각 프로바이더에 무엇을 전송하는가?

메서드란 호출되는 연산을 말하며, 예를 들어 eth_getBalance이나 eth_getLogs과 같은 것입니다. 페이로드란 해당 메서드를 실행하기 위해 보내는 전체 요청으로, 파라미터를 포함합니다. 이 구분이 중요한 이유는 성능이 두 가지 모두에 좌우되기 때문입니다. 저렴한 조회와 대규모 range scan은 프로바이더에 매우 다른 부하를 주며, 단일 메서드라도 입력값에 따라 달라질 수 있습니다.

특정 메서드에 대해 모든 프로바이더는 표준 유료 계정에서 동일하게 구성된 JSON-RPC 페이로드를 받습니다. 이것이 공정성 규칙입니다. 동일한 메서드, 동일한 파라미터, 동일한 체인, 동일한 지역, 동일한 타임아웃, 동일한 성공 기준, 그리고 어떤 프로바이더에 대해서도 특별 대우 없음을 의미합니다.

현재 대부분의 체인에서는 7개, Ethereum에서는 8개의 구성된 테스트를 실행합니다.

eth_getBalance: 계정 잔액 조회
earliest 블록에서의 eth_getBlockByNumber: 체인 시작 지점의 헤더 읽기
latest 블록에서의 eth_getBlockByNumber: 체인 헤드에서의 헤더 읽기
1블록 범위에 대한 eth_getLogs
10블록 범위에 대한 eth_getLogs
100블록 범위에 대한 eth_getLogs
1,000블록 범위에 대한 eth_getLogs (Ethereum 전용)
eth_getTransactionReceipt: 단일 트랜잭션 영수증 조회

일부 페이로드는 체인과 함께 움직입니다. 예를 들어 latest 블록 태그를 사용하는 호출은 체인이 진행됨에 따라 값이 바뀝니다. 다른 페이로드는 고정된 과거 입력값을 사용합니다. Ethereum의 eth_getLogs 테스트는 LINK 토큰 컨트랙트에 대해 구성된 과거 블록 범위를 사용합니다.

이러한 혼합은 의도적입니다.

고정 입력값은 테스트 일부를 재현 가능하게 만듭니다.
움직이는 입력값은 테스트 일부가 실시간 체인 상태를 반영하게 합니다.
고정된 과거 입력값은 프로바이더가 캐싱하기 더 쉬울 수 있습니다.

RPC 성능은 메서드, 파라미터, 블록 범위, 응답 크기, 캐시 동작, 체인 상태에 따라 크게 달라질 수 있습니다. 벤치마크를 읽을 때는 본인의 워크로드와 가장 가까운 메서드와 파라미터에 주목하세요.

성능은 어떻게 측정되는가?

성능은 서로 다른 질문에 답하는 두 가지 신호로 측정합니다. 레이턴시는 성공한 응답이 얼마나 빨리 돌아오는지(평균, p50, p95로 보고), 성공률은 요청이 애초에 얼마나 자주 성공하는지(그 뒤에 있는 실패 요청 수와 함께)입니다.

이 둘은 연관되어 있지만 별개입니다. 빠르게 성공하는 응답이 반드시 신뢰할 수 있는 응답은 아닙니다. 저희는 어느 하나가 다른 하나를 가리지 않도록 둘을 나란히 보고합니다.

레이턴시는 어떻게 측정되는가?

레이턴시는 성공한 JSON-RPC HTTP POST 요청에 대해 러너가 측정한 요청-응답 시간입니다. 러너가 요청을 보낼 때 타이머가 시작되고, 응답을 받으면 멈춥니다. 프로바이더가 120밀리초 만에 유효한 응답을 반환하면, 해당 요청의 레이턴시는 120ms입니다.

저희는 워밍업되고 재사용되는 HTTP 연결을 사용합니다. 쉽게 말해, DNS 조회, TCP 연결 설정, TLS 핸드셰이크와 같이 새 연결을 여는 데 필요한 초기 설정 단계는 시간을 재지 않습니다. 러너가 먼저 연결을 프라이밍한 다음, 풀링된 keep-alive 연결을 통해 POST 자체만 측정합니다.

이렇게 하면 레이턴시 수치가 클라이언트가 일반적으로 연결을 재사용하는 반복 애플리케이션 트래픽에 더 가까워집니다. 다만 이 수치를 콜드 첫 요청 레이턴시로 읽어서는 안 된다는 의미이기도 합니다.

성공한 응답만 레이턴시 분포에 포함됩니다. 요청이 타임아웃되거나, HTTP 에러를 반환하거나, JSON-RPC 에러 객체를 반환하거나, 파싱에 실패하거나, 네트워크 에러가 발생하면 실패한 시도로 집계합니다.

타임아웃은 8,000ms의 느린 응답으로 처리되지 않습니다. 레이턴시 계산에서는 제외하고 성공률에 집계하여, 레이턴시는 응답 속도에, 성공률은 신뢰성에 초점을 맞추도록 유지합니다.

성공률이란?

성공률은 벤치마크 규칙에 따라 성공적으로 반환된 요청의 비율입니다. 즉 성공한 요청 수를 시도한 전체 요청 수로 나눈 값입니다.

다음 조건을 모두 충족해야 요청이 성공으로 집계됩니다.

벤치마크 타임아웃 이전에 완료됩니다.
HTTP 2xx 상태를 반환합니다.
응답 본문이 JSON으로 파싱됩니다.
JSON-RPC 응답에 null이 아닌 error 객체가 포함되어 있지 않습니다.

실패한 시도를 숨기기 위해 재시도를 사용하지 않습니다. 시도된 요청 하나당 기회는 한 번뿐입니다. 실패하면 그 실패가 집계됩니다.

벤치마크는 타임아웃을 어떻게 처리하는가?

벤치마크 러너는 각 프로바이더가 유효한 응답을 반환할 때까지 최대 8초를 기다립니다. 제시간에 유효한 응답이 오지 않으면 해당 시도를 타임아웃 실패로 기록합니다.

8초라는 기준은 저희 테스트 설정의 일부입니다. 이는 체인이 정한 것도 아니고, 프로바이더가 내부적으로 사용할 수 있는 어떤 타임아웃 값도 아닙니다.

8초 기준은 현재 모든 공개 EVM read 메서드에 적용됩니다. 특정 메서드에 다른 타임아웃을 설정할 수도 있지만, 현재는 그런 메서드가 없습니다.

실패한 요청은 무엇으로 간주되는가?

실패한 시도는 레이턴시와 별도로 추적합니다. 다음의 경우 요청을 실패로 집계합니다.

403, 429, 500, 502, 503, 504와 같은 2xx가 아닌 HTTP 상태를 반환하는 경우
JSON-RPC 에러 객체를 반환하는 경우
8초 후 타임아웃되는 경우
네트워크 수준에서 실패하는 경우
유효한 JSON으로 파싱되지 않는 경우

레이트 리밋 응답도 실패로 집계되며, 실패한 시도를 성공으로 바꾸기 위해 재시도를 사용하는 일은 결코 없습니다. 각 실패는 해당 메서드, 체인, 지역, 시간대에서 프로바이더의 성공률을 낮추고 실패 요청 수를 늘립니다.

지표는 어떻게 정의되는가?

Metric	Technical definition	Plain-English meaning	Important caveat
Average latency	Sum of successful response times divided by count of successful responses.	On successful calls, how long did the provider take on average?	Excludes failures, so it must be read with success rate.
p50 latency	Median latency across successful responses in the same provider, chain, method, region, and window group.	The typical successful response time.	Can hide slower tail behavior.
p95 latency	The latency point where 95% of successful responses were faster and 5% were slower.	How slow successful requests get outside the normal case.	Timeouts are not included as 8-second samples; they count as failures.
Success rate	Successful requests divided by total attempted requests.	How often the provider returned successfully under the test rules.	The reliability companion to latency.
Failed requests	Count of attempts that did not meet the success criteria.	How many requests failed.	Shown as counts per method; the flip side of success rate.

레이턴시와 성공률을 함께 보고하는 이유는?

응답이 실제로 돌아와야만 빠른 응답이 의미가 있습니다. 어떤 프로바이더는 성공한 요청에서는 낮은 레이턴시를 보이면서도 더 자주 타임아웃되거나 실패할 수 있으므로, 저희는 레이턴시를 성공률과 함께 보고합니다. 레이턴시는 유효한 응답이 얼마나 빨리 돌아오는지를, 성공률은 응답이 애초에 얼마나 자주 돌아오는지를 보여줍니다.

예를 들어 1,000번 시도해서 990번이 8초 타임아웃 이전에 성공적으로 반환되었다면 성공률은 99%입니다. 실패한 10건은 p50, p95, 평균 레이턴시에 포함되지 않고 신뢰성 실패로 나타납니다.

이렇게 하면 두 가지 오독을 방지할 수 있습니다. 레이턴시는 낮지만 실패가 더 많은 프로바이더를 속도만으로 평가해서는 안 되고, 성공률은 높지만 테일 레이턴시가 느린 프로바이더를 신뢰성만으로 평가해서도 안 됩니다.

벤치마크가 추적 시간대(trailing window)를 사용하는 이유는?

이 벤치마크는 지속적으로 실행됩니다. 일반적인 공개 EVM read 메서드는 약 10초마다 실행되며, 공개 벤치마크 페이지는 24시간 추적 시간대를 기준으로 5분마다 새로고침됩니다.

완전 가동 상태에서, 10초마다 실행되는 메서드는 프로바이더, 메서드, 네트워크, 지역별로 하루에 약 8,640번의 시도를 생성합니다. 24시간 추적 시간대는 각 공개 수치에 일회성 변동을 완화할 만큼 충분한 샘플을 제공하면서도 페이지를 최신 상태로 유지합니다.

따라서 공개 페이지는 단일 요청, 일회성 테스트, 순간적인 스냅샷이 아니라 일 단위 롤링 요약으로 읽어야 합니다.

벤치마크가 측정하지 않는 것은?

현재 이 벤치마크는 통제된 조건에서의 웜(warm) 상태 단일 메서드 read 성능을 측정합니다. 다음은 측정하지 않습니다.

다중 호출 사용자 플로우
쓰기 트랜잭션 또는 트랜잭션 제출
WebSocket 또는 구독(subscription) 동작
고객사별 요청 조합
콜드 첫 요청 연결 설정
모든 프로바이더, 체인, 지역, 메서드, 페이로드 형태
여러분 자신의 아키텍처, 트래픽 수준, 배포 지역의 정확한 동작

이러한 경계가 있기 때문에 벤치마크가 유용합니다. 즉 이 수치가 어디에 적용되는지, 그리고 어디에서는 여러분 스스로 워크로드에 맞는 테스트를 실행해야 하는지를 알려줍니다.

속도와 신뢰성은 연관되어 있지만 별개의 질문입니다.

속도는 성공한 요청이 얼마나 빨리 돌아오는지를 묻습니다.
신뢰성은 요청이 얼마나 자주 성공적으로 돌아오는지를 묻습니다.

저희는 이 구분을 "가장 빠른 프로바이더"라는 단일 주장으로 뭉뚱그리지 않고 그대로 드러내도록 벤치마크를 설계했습니다.

개발자는 결과를 어떻게 활용해야 하는가?

공개 벤치마크를 프로바이더 평가의 출발점으로 활용하세요. 실용적인 읽기 방법은 다음과 같습니다.

여러분의 워크로드와 가장 가까운 체인과 메서드를 선택합니다.
사용자나 인프라가 위치한 곳과 가장 잘 맞는 지역을 비교합니다.
평균이나 p50뿐만 아니라 p95도 확인합니다.
레이턴시 옆의 성공률을 확인합니다.
워크로드가 다른 페이로드, 더 높은 동시성, 쓰기, WebSocket, 다중 호출 플로우를 사용한다면, 결정을 내리기 전에 워크로드에 맞는 벤치마크를 직접 실행하세요.

투명한 벤치마크는 더 나은 질문을 던지는 데 도움이 됩니다. 무엇이 테스트되었는지, 무엇이 집계되었는지, 무엇이 제외되었는지, 그리고 실제 애플리케이션에서 어떤 부분이 가장 중요한지를 더 쉽게 파악할 수 있게 해줍니다.

자주 묻는 질문

Alchemy의 공개 EVM read 벤치마크란?

RPC 프로바이더들이 일반적인 EVM JSON-RPC read 요청을 어떻게 처리하는지 측정하는 통제된 테스트입니다. 선택된 프로바이더, 체인, 메서드, 지역에 걸쳐 성공 응답 레이턴시(평균, p50, p95), 성공률, 실패 요청 수를 기록하여, 개발자가 마케팅 주장이 아니라 동일하고 재현 가능한 조건에서 프로바이더를 비교할 수 있게 합니다.

RPC 레이턴시는 어떻게 측정하는가?

레이턴시는 워밍업되고 재사용되는 연결을 통해 하나의 JSON-RPC POST와 그 응답에 대해 러너가 측정한 실제 소요 시간(wall-clock time)입니다. 요청을 보낼 때 타이머가 시작되고 유효한 응답이 도착하면 멈춥니다. 성공한 응답만 집계되므로, 레이턴시는 연결 설정이나 실패가 아니라 응답 속도를 반영합니다.

성공한 요청이란 무엇을 의미하는가?

요청은 8초 타임아웃 이내에 반환되고, HTTP 2xx 상태를 반환하고, JSON으로 파싱되며, JSON-RPC 에러 객체를 포함하지 않아야만 성공으로 간주됩니다. 타임아웃, HTTP 에러, 레이트 리밋 응답을 포함한 그 외의 모든 경우는 실패한 시도로 집계되어 레이턴시에서 제외됩니다.

벤치마크는 타임아웃을 어떻게 처리하는가?

러너는 유효한 응답을 최대 8초까지 기다립니다. 응답이 오지 않으면 해당 시도를 8,000ms짜리 느린 응답이 아니라 타임아웃 실패로 기록합니다. 타임아웃은 성공률을 낮추지만 레이턴시를 부풀리는 일은 없으며, 이를 통해 속도와 신뢰성을 별개의 측정값으로 유지합니다.

벤치마크는 재시도를 사용하는가?

아니요. 각 측정은 단 한 번의 시도입니다. 그 시도가 실패하면 재시도로 감추지 않고 실패로 집계합니다. 이는 실제 애플리케이션이 겪는 간헐적 실패를 재시도가 가려버리지 않도록, 성공률을 정직하게 유지합니다.

벤치마크는 어떤 체인과 프로바이더를 다루는가?

공개 벤치마크는 Ethereum, Optimism, Arbitrum, Base, World Chain 메인넷을 다룹니다. 프로바이더 목록에는 Alchemy, dRPC, Infura, QuickNode가 포함됩니다. 특정 메서드에 대해 각 프로바이더는 동일한 지역에서, 동일한 타임아웃과 성공 규칙 아래, 동일하게 구성된 요청을 받습니다.

벤치마크는 어떤 RPC 메서드를 테스트하는가?

벤치마크는 네 가지 EVM 메서드를 바탕으로 구성된 7개의 read 테스트를 실행합니다. eth_getBalance; 가장 이른 블록과 가장 최근 블록에서의 eth_getBlockByNumber; 1블록, 10블록, 100블록 범위에 대한 eth_getLogs; 그리고 eth_getTransactionReceipt입니다. Ethereum은 1,000블록 eth_getLogs 테스트를 추가하여 8개가 됩니다. 각각 고정된 페이로드를 사용하므로 프로바이더 간 결과를 비교할 수 있습니다.

벤치마크가 측정하지 않는 것은?

전체 애플리케이션 워크플로, 쓰기 트랜잭션, WebSocket 구독, 고객사별 트래픽 조합, 콜드 연결 설정은 측정하지 않습니다. 또한 모든 체인, 프로바이더, 지역, 메서드, 페이로드를 다루지도 않습니다. 이러한 경우에는 자신의 트래픽에 맞는 워크로드별 벤치마크를 직접 실행해야 합니다.

p95 레이턴시 수치는 어떻게 읽어야 하는가?

p95는 다음과 같이 읽어야 합니다. 해당 메서드, 체인, 지역, 시간대에서 성공한 응답의 95%가 적어도 이만큼은 빨랐다는 뜻입니다. 이는 평균이 가려버리는 테일 동작을 드러냅니다. 응답이 실제로 돌아와야만 빠른 응답이 의미가 있으므로, 항상 성공률과 함께 읽어야 합니다.

Alchemy 뉴스레터

출시 소식을 가장 먼저 받아보세요

뉴스레터 구독하기

Alchemy의 최신 제품 업데이트와 리소스 받기

구독자 80,000명 이상

이메일 주소를 입력하면 마케팅 커뮤니케이션 및 제품 업데이트 수신에 동의하게 됩니다. Alchemy는 저희 개인정보 처리방침에 따라 수집한 정보를 처리합니다. 언제든지 구독을 취소할 수 있습니다.

RPC 성능을 벤치마크하는 방법

Alchemy의 공개 EVM read 벤치마크란?

정의 및 측정 규칙

벤치마크는 무엇을 다루는가?

벤치마크는 각 프로바이더에 무엇을 전송하는가?

성능은 어떻게 측정되는가?

레이턴시는 어떻게 측정되는가?

성공률이란?

벤치마크는 타임아웃을 어떻게 처리하는가?

실패한 요청은 무엇으로 간주되는가?

지표는 어떻게 정의되는가?

레이턴시와 성공률을 함께 보고하는 이유는?

벤치마크가 추적 시간대(trailing window)를 사용하는 이유는?

벤치마크가 측정하지 않는 것은?

개발자는 결과를 어떻게 활용해야 하는가?

자주 묻는 질문

Alchemy의 공개 EVM read 벤치마크란?

RPC 레이턴시는 어떻게 측정하는가?

성공한 요청이란 무엇을 의미하는가?

벤치마크는 타임아웃을 어떻게 처리하는가?

벤치마크는 재시도를 사용하는가?

벤치마크는 어떤 체인과 프로바이더를 다루는가?

벤치마크는 어떤 RPC 메서드를 테스트하는가?

벤치마크가 측정하지 않는 것은?

p95 레이턴시 수치는 어떻게 읽어야 하는가?

Alchemy 뉴스레터

뉴스레터 구독하기

관련 아티클

Glamsterdam: Ethereum 개발자를 위한 완전 가이드

도쿄에서 구축한다면 어떤 RPC 제공업체를 선택해야 할까

업계 최고 수준의 속도와 안정성을 위한 Solana RPC 읽기 아키텍처