SignalR 성능(SignalR 1.x)
경고
이 설명서는 최신 버전의 SignalR용이 아닙니다. ASP.NET Core SignalR을 살펴보세요.
이 항목에서는 SignalR 애플리케이션에서 성능을 설계, 측정 및 개선하는 방법을 설명합니다.
SignalR 성능 및 크기 조정에 대한 최근 프레젠테이션은 ASP.NET SignalR을 사용하여 실시간 웹 크기 조정을 참조하세요.
이 항목에는 다음과 같은 섹션이 포함되어 있습니다.
디자인 고려 사항
이 섹션에서는 불필요한 네트워크 트래픽을 생성하여 성능이 저하되지 않도록 SignalR 애플리케이션을 디자인하는 동안 구현할 수 있는 패턴을 설명합니다.
메시지 빈도 제한
높은 빈도(예: 실시간 게임 애플리케이션)로 메시지를 보내는 애플리케이션에서도 대부분의 애플리케이션은 1초에 몇 개 이상의 메시지를 보낼 필요가 없습니다. 각 클라이언트가 생성하는 트래픽의 양을 줄이기 위해 메시지를 큐에 대기하고 보내는 메시지 루프를 구현하여 고정 속도보다 더 자주 메시지를 보낼 수 있습니다(즉, 전송할 시간 간격에 메시지가 있는 경우 매초에 최대 특정 수의 메시지가 전송됨). 클라이언트와 서버 모두에서 메시지를 특정 속도로 제한하는 샘플 애플리케이션은 SignalR을 사용하여 고주파 실시간을 참조하세요.
메시지 크기 줄이기
직렬화된 개체의 크기를 줄여 SignalR 메시지의 크기를 줄일 수 있습니다. 서버 코드에서 전송할 필요가 없는 속성이 포함된 개체를 보내는 경우 특성을 사용하여 JsonIgnore
해당 속성이 직렬화되지 않도록 합니다. 속성의 이름도 메시지에 저장됩니다. 속성을 사용하여 JsonProperty
속성 이름을 줄일 수 있습니다. 다음 코드 샘플에서는 클라이언트로 전송되는 속성을 제외하는 방법과 속성 이름을 줄이는 방법을 보여 줍니다.
클라이언트로 전송되는 데이터를 제외하는 JsonIgnore 특성과 메시지 크기를 줄이기 위한 JsonProperty 특성을 보여 주는 .NET 서버 코드
using Newtonsoft.Json;
using System;
public class ShapeModel
{
[JsonProperty("l")]
public double Left { get; set; }
[JsonProperty("t")]
public double Top { get; set; }
// We don't want the client to get the "LastUpdatedBy" property
[JsonIgnore]
public string LastUpdatedBy { get; set; }
}
클라이언트 코드에서 가독성/유지 관리를 유지하기 위해 메시지를 받은 후 약어 속성 이름을 사람 친화적인 이름으로 다시 매핑할 수 있습니다. 다음 코드 샘플에서는 메시지 계약(매핑)을 정의하고 함수를 사용하여 reMap
최적화된 메시지 클래스에 계약을 적용하여 단축된 이름을 더 긴 이름으로 다시 매핑하는 한 가지 방법을 보여 줍니다.
단축된 속성 이름을 사람이 읽을 수 있는 이름으로 다시 매핑하는 클라이언트 쪽 JavaScript 코드
function reMap(smallObject, contract) {
var largeObject = {};
for (var smallProperty in contract) {
largeObject[contract[smallProperty]] = smallObject[smallProperty];
}
return largeObject;
}
var shapeModelContract = {
l: "left",
t: "top"
};
myHub.client.setShape = function (shapeModelSmall) {
var shapeModel = reMap(shapeModelSmall, shapeModelContract);
// shapeModelSmall has "l" and "t" properties but after remapping
// shapeModel now has "left" and "top" properties
};
동일한 메서드를 사용하여 클라이언트에서 서버로의 메시지에서도 이름을 줄일 수 있습니다.
메시지 개체의 메모리 공간(즉, 메시지에 사용된 메모리 양)을 줄이면 성능도 향상될 수 있습니다. 예를 들어 의 전체 범위 int
가 필요하지 않은 경우 또는 byte
를 short
대신 사용할 수 있습니다.
메시지는 서버 메모리의 메시지 버스에 저장되므로 메시지 크기를 줄이면 서버 메모리 문제도 해결할 수 있습니다.
성능을 위해 SignalR 서버 튜닝
다음 구성 설정을 사용하여 SignalR 애플리케이션에서 성능을 향상하기 위해 서버를 조정할 수 있습니다. ASP.NET 애플리케이션의 성능을 개선하는 방법에 대한 일반적인 정보는 ASP.NET 성능 향상을 참조하세요.
SignalR 구성 설정
DefaultMessageBufferSize: 기본적으로 SignalR은 연결당 허브당 1000개의 메시지를 메모리에 유지합니다. 큰 메시지를 사용하는 경우 이 값을 줄여 완화할 수 있는 메모리 문제가 발생할 수 있습니다. 이 설정은 ASP.NET 애플리케이션의
Application_Start
이벤트 처리기 또는Configuration
자체 호스팅 애플리케이션의 OWIN 시작 클래스 메서드에서 설정할 수 있습니다. 다음 샘플에서는 사용되는 서버 메모리 양을 줄이기 위해 애플리케이션의 메모리 공간을 줄이기 위해 이 값을 줄이는 방법을 보여 줍니다.기본 메시지 버퍼 크기를 줄이기 위한 Global.asax의 .NET 서버 코드
protected void Application_Start(object sender, EventArgs e) { GlobalHost.Configuration.DefaultMessageBufferSize = 500; }
IIS 구성 설정
애플리케이션당 최대 동시 요청: 동시 IIS 요청 수를 늘리면 요청을 제공하는 데 사용할 수 있는 서버 리소스가 증가합니다. 기본값은 5000입니다. 이 설정을 늘리려면 관리자 권한 명령 프롬프트에서 다음 명령을 실행합니다.
cd %windir%\System32\inetsrv\ appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:10000
ASP.NET 구성 설정
이 섹션에는 파일에서 설정할 수 있는 구성 설정이 aspnet.config
포함되어 있습니다. 이 파일은 플랫폼에 따라 두 위치 중 하나에서 찾을 수 있습니다.
%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet.config
%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
SignalR 성능을 향상시킬 수 있는 ASP.NET 설정은 다음과 같습니다.
CPU당 최대 동시 요청: 이 설정을 늘리면 성능 병목 현상이 완화될 수 있습니다. 이 설정을 늘리려면 파일에 다음 구성 설정을
aspnet.config
추가합니다.<?xml version="1.0" encoding="UTF-8" ?> <configuration> <system.web> <applicationPool maxConcurrentRequestsPerCPU="20000" /> </system.web> </configuration>
요청 큐 제한: 총 연결 수가 설정을 초과
maxConcurrentRequestsPerCPU
하면 ASP.NET 큐를 사용하여 요청을 제한하기 시작합니다. 큐의 크기를 늘리려면 설정을 늘릴requestQueueLimit
수 있습니다. 이렇게 하려면 의 노드config/machine.config
에 다음 구성 설정을processModel
추가합니다(대신aspnet.config
).<processModel autoConfig="false" requestQueueLimit="250000" />
성능 문제 해결
이 섹션에서는 애플리케이션에서 성능 병목 상태를 찾는 방법을 설명합니다.
WebSocket이 사용되고 있는지 확인
SignalR은 클라이언트와 서버 간의 통신에 다양한 전송을 사용할 수 있지만 WebSocket은 상당한 성능 이점을 제공하며 클라이언트와 서버에서 지원하는 경우 사용해야 합니다. 클라이언트와 서버가 WebSocket에 대한 요구 사항을 충족하는지 확인하려면 전송 및 대체를 참조하세요. 애플리케이션에서 사용 중인 전송을 확인하려면 브라우저 개발자 도구를 사용하고 로그를 검사하여 연결에 사용되는 전송을 확인할 수 있습니다. 인터넷 Explorer 및 Chrome에서 브라우저 개발 도구를 사용하는 방법에 대한 자세한 내용은 전송 및 대체를 참조하세요.
SignalR 성능 카운터 사용
이 섹션에서는 패키지에 있는 Microsoft.AspNet.SignalR.Utils
SignalR 성능 카운터를 사용하도록 설정하고 사용하는 방법을 설명합니다.
signalr.exe 설치
성능 카운터는 SignalR.exe라는 유틸리티를 사용하여 서버에 추가할 수 있습니다. 이 유틸리티를 설치하려면 다음 단계를 수행합니다.
Visual Studio에서 도구>NuGet 패키지 관리자>솔루션용 NuGet 패키지 관리를 선택합니다.
signalr.utils를 검색하고 설치를 선택합니다.
사용권 계약에 동의하여 패키지를 설치합니다.
SignalR.exe 에 설치됩니다
<project folder>/packages/Microsoft.AspNet.SignalR.Utils.<version>/tools
.
SignalR.exe 사용하여 성능 카운터 설치
SignalR 성능 카운터를 설치하려면 다음 매개 변수를 사용하여 관리자 권한 명령 프롬프트에서 SignalR.exe 실행합니다.
SignalR.exe ipc
SignalR 성능 카운터를 제거하려면 다음 매개 변수를 사용하여 관리자 권한 명령 프롬프트에서 SignalR.exe 실행합니다.
SignalR.exe upc
SignalR 성능 카운터
유틸리티 패키지는 다음 성능 카운터를 설치합니다. "합계" 카운터는 마지막 애플리케이션 풀 또는 서버를 다시 시작한 이후의 이벤트 수를 측정합니다.
연결 메트릭
다음 메트릭은 발생하는 연결 수명 이벤트를 측정합니다. 자세한 내용은 연결 수명 이벤트 이해 및 처리를 참조하세요.
- 연결된 연결
- 연결 다시 연결됨
- 연결 끊김
- 연결 현재
메시지 메트릭
다음 메트릭은 SignalR에서 생성된 메시지 트래픽을 측정합니다.
- 총 수신된 연결 메시지
- 총 전송된 연결 메시지
- 연결 메시지 수신/초
- 보낸 연결 메시지/초
메시지 버스 메트릭
다음 메트릭은 들어오고 나가는 모든 SignalR 메시지가 배치되는 큐인 내부 SignalR 메시지 버스를 통해 트래픽을 측정합니다. 메시지를 보내거나 브로드캐스트할 때 게시 됩니다. 이 컨텍스트의 구독자는 메시지 버스의 구독입니다. 이는 클라이언트 수와 서버 자체와 같아야 합니다. 할당된 작업자는 활성 연결로 데이터를 보내는 구성 요소입니다. 사용 중인 작업자는 메시지를 적극적으로 보내는 작업자입니다.
- 메시지 버스 메시지 수신 총
- Message Bus 메시지 수신/초
- 게시된 메시지 버스 메시지 합계
- Message Bus Messages Published/Sec
- Message Bus 구독자 현재
- Message Bus 구독자 합계
- Message Bus 구독자/초
- Message Bus 할당 작업자
- 메시지 버스 사용 중인 작업자
- Message Bus 토픽 현재
오류 메트릭
다음 메트릭은 SignalR 메시지 트래픽에서 생성된 오류를 측정합니다. 허브 또는 허브 메서드를 확인할 수 없는 경우 허브 확인 오류가 발생합니다. 허브 호출 오류는 허브 메서드를 호출하는 동안 throw된 예외입니다. 전송 오류는 HTTP 요청 또는 응답 중에 throw된 연결 오류입니다.
- 오류: 총합계
- 오류: All/Sec
- 오류: 허브 해상도 합계
- 오류: 허브 해결/초
- 오류: 허브 호출 합계
- 오류: 허브 호출/초
- 오류: 전송 합계
- 오류: Transport/Sec
스케일 아웃 메트릭
다음 메트릭은 스케일 아웃 공급자가 생성한 트래픽 및 오류를 측정합니다. 이 컨텍스트의 Stream은 스케일 아웃 공급자가 사용하는 배율 단위입니다. 이 테이블은 SQL Server 사용되는 경우 테이블이고, Service Bus를 사용하는 경우 토픽, Redis를 사용하는 경우 구독입니다. 기본적으로 하나의 스트림만 사용되지만 SQL Server 및 Service Bus의 구성을 통해 늘릴 수 있습니다. 버퍼링 스트림은 오류 상태를 입력한 스트림입니다. 스트림이 오류 상태이면 스트림에 더 이상 오류가 발생하지 않을 때까지 백플레인으로 전송된 모든 메시지가 즉시 실패합니다. 큐 보내기 길이는 게시되었지만 아직 전송되지 않은 메시지의 수입니다.
- Scaleout Message Bus Messages Received/Sec
- 규모 확장 스트림 합계
- 확장 스트림 열기
- 스케일 아웃 스트림 버퍼링
- 규모 확장 오류 합계
- 규모 확장 오류/초
- 확장 송신 큐 길이
이러한 카운터가 측정하는 항목에 대한 자세한 내용은 Azure Service Bus 사용하여 SignalR Scaleout을 참조하세요.
다른 성능 카운터 사용
다음 성능 카운터는 애플리케이션의 성능을 모니터링하는 데 유용할 수도 있습니다.
메모리
- 모든 힙의 .NET CLR 메모리# 바이트(w3wp의 경우)
ASP.NET
- ASP.NET\Requests Current
- ASP.NET\Queued
- ASP.NET\거부됨
CPU
- 프로세서 정보\프로세서 시간
TCP/IP
- TCPv6/연결 설정됨
- TCPv4/연결 설정됨
웹 서비스
- 웹 서비스\현재 연결
- 웹 서비스\최대 연결
스레딩
- 현재 논리 스레드의 .NET CLR LocksAndThreads#
- .NET CLR 잠금 및 현재 실제 스레드의 스레드#
기타 리소스
ASP.NET 성능 모니터링 및 튜닝에 대한 자세한 내용은 다음 topics 참조하세요.