예 1: 많은 사물, 적은 속성 및 낮은 쓰기 빈도
시나리오
예 1에 대한 상위 수준 시나리오 개요
영역 전체에서 100,000개의 펌프 모니터링. 각 펌프는 5분마다 20개의 속성 값을 ThingWorx에 보고합니다. 최대 사용자 액세스 기간 동안 1시간에 10개의 매쉬업(각각 10개의 서비스 포함)을 1,000명의 사용자가 호출합니다. 이 ThingWorx 구성은 Microsoft SQL Server 데이터베이스를 사용합니다.
요구사항
• 사물 수(T): 100,000개의 사물
• 속성 수(P): 20개의 속성
• 쓰기 빈도(FD): 5분마다 또는 하루 288회의 쓰기
• 최대 사용량 기간(t): 1시간 또는 3600초
• 매쉬업 수(M): 10개의 매쉬업
• 사용자 수(U): 1,000명의 사용자
• 매쉬업당 서비스 수(SM): 10개의 서비스
• 사용자가 각 매쉬업을 로드하는 횟수(LM): 2회
계산
• 데이터 수집:
WPS = T × [(P1 × F1)]
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
= 100,000 × [(20 × 288/86400)]
≈ 6,667 writes per second
 | 이 계산에서는 모든 20개의 장치 속성에 대한 쓰기 빈도가 동일하기 때문에 합계가 필요하지 않습니다. |
연결 서버 값도 계산하는 것을 잊지 마십시오.
CS = T / 100,000
= 100,000 / 100,000
= 1 Connection Server
= 100,000 / 100,000
= 1 Connection Server
• 데이터 시각화:
R = [(SM + 1) × UM × LM ] / t
= [(10 + 1) × 1000 × 2 ] / 3600
≈ 6.11 requests per second
= [(10 + 1) × 1000 × 2 ] / 3600
≈ 6.11 requests per second
여기서 합계를 구하려면 매쉬업당 모든 사용자에 대한 HTTP 요청 수((SM + 1) x UM으로 제공됨)를 총 매쉬업 수(M)로 곱하면 됩니다. 이렇게 하는 이유는 모든 매쉬업이 동일한 양의 트래픽을 예상하며 동일한 수의 서비스를 포함할 것으로 가정되기 때문입니다. 그러므로 결과는 다음과 같습니다.
R = R1 × M
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
≈ 6.11 × 10 ≈ 61.1 HTTP Requests per second
조건 비교
• T = 100,000 -> "중규모" 플랫폼(또는 중규모 이상, Microsoft SQL Server 사용)
• CS = 1 -> 한 개의 연결 서버 권장
• WPS = 6,667 -> "소규모" 플랫폼(또는 소규모 이상)
• R = 61 -> "중규모" 플랫폼(또는 중규모 이상)
크기 조정
"중규모" ThingWorx 시스템이 모든 조건을 충족해야 한다는 점을 감안하면 호스팅 유형을 기준으로 다음 크기 조정을 고려해야 합니다.
크기 | Azure VM | AWS EC2 | CPU 코어 수 | 메모리(GiB) |
|---|---|---|---|---|
ThingWorx Platform: 중규모 | F16s v2 | C5d.4xlarge | 16개 | 32개 |
Microsoft SQL Server DB: 중규모 | F16s v2 | C5d.4xlarge | 16개 | 32개 |
ThingWorx Connection Server | F2s v2 | C5d.large | 2개 | 4개 |
Connection Services 도움말 센터에서 연결 서버 크기 조정에 대한 내용을 검토하는 것을 잊지 마십시오. 이러한 크기 조정은 이 안내서의 T를 사용할 뿐만 아니라 에지 요청(WebSocket 포함), 속성 업데이트, 파일 전송 및 평균 메시지 크기와 같은 요소도 고려합니다.
계산되고 관찰된 결과 비교
예 1에서는 다양한 매쉬업보다 플랫폼에 연결된 사물 수에 더 중점을 둔 연결된 제품 솔루션 사용 사례를 시뮬레이션합니다. 실제 시나리오에서는 매쉬업당 서비스 수와 각 매쉬업에 액세스하는 사용자 수(예 2 참조) 모두에서 차이가 더 많이 납니다.
인프라 측면을 봤을 때 플랫폼은 평균적으로 CPU의 51.6%를 사용하고 5.3GB 메모리를 사용했기 때문에 성능이 좋았습니다. MS SQL은 평균적으로 CPU의 16.7%를 사용했고 13.9GB의 메모리를 사용했습니다.
플랫폼 측면을 봤을 때 HTTP 요청 속도에서는 평균적으로 초당 62개의 작업을 수행해서 예상 61 OPS와 비슷했고, 실제 가치 스트림 대기열 속도는 약 7k WPS(위의 예상 6.7k WPS에 근접)로 안정적이었습니다.
일반 작업에서 SQL Server는 대개 가능한 한 많은 메모리를 사용하려고 합니다. 이에 따라 SQL Server는 전용 시스템에 있으며 가능한 한 많은 데이터를 메모리에 저장한다고 가정합니다. 이러한 점은 위의 메모리 사용 차트에서 확인할 수 있습니다. 이 테스트의 거의 끝 근처에서만 사용량이 수평을 유지하고 운영 체제에 대해서는 소규모 풀이 남아 있습니다.
이 인프라는 이 인프라에 대해 수행된 크기 조정 테스트 기간 동안 안정적이지만, 데이터베이스 서버의 크기가 올바르게 조정되도록 보장하는 생산 설정에서 사용하기 전에 더 긴 기간의 테스트가 권장됩니다. 이상적으로는 이러한 테스트는 데이터베이스가 해당 예상 데이터 보존 수준에 도달할 때까지입니다.