이 시나리오에서는 모든 데이터를 서버에서 사용할 수 있었고 모든 샘플을 처리하는 데 걸리는 시간을 측정했습니다. 우리는 테스트 결과로 초당 샘플 수의 대역폭을 보고합니다. 두 개 이상의 컴퓨팅 서버가 사용된 경우 모든 서버의 총 대역폭을 합산하여 보고합니다. 세 가지 사용 사례에 대한 결과는 아래 그림에 나와 있습니다. 두 대의 서버인 경우 두 서버의 결합된 대역폭을 보고합니다.

결과는 네트워크 스토리지가 성능에 부정적인 영향을 미치지 않는다는 것을 보여줍니다. 변화는 미미하고 일부 작업에서는 아무런 변화가 발견되지 않았습니다. 두 번째 서버를 추가하면 총 대역폭이 정확히 두 배가 되거나 최악의 경우 변화가 1% 미만이 됩니다.

이 벤치마크는 지연 시간을 측정합니다. 여러 개의 계산 서버가 있는 경우의 평균 지연 시간을 보고합니다. 각 작업에 대한 결과는 아래 그림과 같습니다. 두 대의 서버 사례에서는 두 서버의 평균 지연 시간을 보고합니다.

결과는 네트워크 스토리지가 작업을 처리하기에 충분하다는 것을 다시 한번 보여줍니다. 하나의 서버 케이스에서 로컬 스토리지와 네트워크 스토리지의 차이는 미미하거나 전혀 없습니다. 마찬가지로, 두 서버가 동일한 저장소를 사용하는 경우 두 서버의 지연 시간은 동일하게 유지되거나 매우 약간만 변경됩니다.

이 경우 결과는 QoS 제약 조건을 충족하면서 시스템이 처리할 수 있는 스트림 수입니다. 따라서 결과는 항상 정수입니다. 두 개 이상의 서버에 대해 모든 서버에서 합산된 총 스트림 수를 보고합니다. 모든 워크로드가 이 시나리오를 지원하는 것은 아니지만, 지원하는 워크로드는 실행해 보았습니다. 테스트 결과는 아래 그림에 요약되어 있습니다. 두 대의 서버 사례에서는 두 서버에서 발생한 스트림의 개수를 합산하여 보고합니다.

결과는 이 설정이 완벽한 성능을 보임을 보여줍니다. 로컬 및 네트워킹 스토리지는 동일한 결과를 제공하며, 두 번째 서버를 추가하면 제안된 설정이 처리할 수 있는 스트림 수가 두 배가 됩니다.

제안된 아키텍처의 성능을 평가하기 위해 다양한 테스트가 실행되었습니다. 6가지 서로 다른 작업 부하(이미지 분류, 객체 감지[소규모], 객체 감지[대규모], 의료 영상, 음성-텍스트 변환, 자연어 처리[NLP])가 오프라인 및 단일 스트림의 두 가지 시나리오에서 실행되었습니다. 결과는 다음 섹션에 설명되어 있습니다.