SOAP의 성능과 SOAP의 성능 비교XML-RPC 또는 REST

https://stackoverflow.com/questions/106546

01-07-2019
|

문제

XML-RPC 또는 REST를 사용하는 솔루션의 단순성에 대한 주장은 이해하기 쉽지만 논쟁하기는 어렵습니다.

또한 SOAP의 오버헤드 증가가 사용된 대역폭은 물론 대기 시간까지 심각한 영향을 미칠 수 있다는 주장을 자주 들었습니다.영향을 정량화하는 테스트 결과를 보고 싶습니다.그러한 정보에 대한 좋은 출처를 아는 사람이 있습니까?

해결책

이에 관해 유익한 몇 가지 연구가 수행되었습니다.다음을 참조하십시오:

또한 주제에 대한 (다소 오래된) 흥미로운 성능 대화가 있습니다. MSDN 포럼.

간단히 말해서, 대부분의 소스는 SOAP와 REST가 범용 데이터에 대해 거의 동일한 성능을 발휘한다는 데 동의하는 것 같습니다.그러나 일부 결과는 이진 데이터의 경우 REST가 실제로 성능이 떨어질 수 있음을 나타내는 것 같습니다.이에 대한 자세한 내용은 제가 링크한 포럼의 링크를 참조하세요.

다른 팁

SOAP와 SOAP 속도의 주요 영향REST는 회선 속도가 아니라 캐시 가능성과 관련이 있습니다.REST는 XML을 통해 웹을 터널링하는 대신 웹의 의미 체계를 사용할 것을 제안하므로 RESTful 웹 서비스는 일반적으로 캐시 헤더를 올바르게 사용하도록 설계되어 캐싱 프록시 및 로컬 브라우저 캐시와 같은 웹의 표준 인프라와 잘 작동합니다.또한 웹의 의미 체계를 사용한다는 것은 ETag 및 자동 zip 압축과 같은 기능이 효율성을 높이는 방법으로 잘 알려져 있음을 의미합니다.

..그리고 이제 벤치마크를 원한다고 말씀하셨습니다.음, Google의 도움으로 찾았습니다. 한 남자 테스트 결과 REST는 SOAP보다 4~6배 더 빠른 것으로 나타났습니다. 종이 이는 또한 REST를 선호합니다.

프로토콜로서의 REST는 어떤 형태의 메시지 봉투도 정의하지 않지만 SOAP에는 이 표준이 있습니다.

따라서 둘을 비교하는 것은 다소 단순합니다. 사과와 오렌지입니다.

즉, SOAP 봉투(데이터 제외)는 단지 몇 k에 불과하므로 SOAP와 REST를 통해 직렬화된 개체를 검색하는 경우 눈에 띄는 속도 차이가 없어야 합니다.

XML을 사용하는 SOAP 및 기타 프로토콜은 일반적으로 메시지를 상당히 부풀립니다. 이는 상황에 따라 문제가 될 수도 있고 그렇지 않을 수도 있습니다.

JSON과 같은 것이 더 컴팩트하고 직렬화/역직렬화 속도가 더 빠를 수도 있지만 그런 이유로만 사용하지는 마세요.당시에 합리적이라고 생각되는 것은 무엇이든 수행하고 문제가 있으면 변경하십시오.

일반적으로 HTTP를 사용하는 모든 것(많은 구현에서 사용하지 않는 HTTP 1.1 연결 유지 연결을 재사용하지 않는 한)은 각 요청에 대해 새로운 TCP 연결을 시작합니다.특히 대기 시간이 긴 링크에서는 이는 매우 나쁩니다.HTTPS는 훨씬 더 나쁩니다.한 발신자에서 한 수신자에게 짧은 요청이 많이 있는 경우 이 오버헤드를 어떻게 제거할 수 있는지 생각해 보세요.

모든 종류의 RPC(SOAP이든 다른 것이든)에 HTTP를 사용하면 항상 오버헤드가 발생합니다.다른 RPC 프로토콜을 사용하면 일반적으로 연결을 열린 상태로 유지할 수 있습니다.

"pjz"의 답변을 확장합니다.

많은 INFORMATION(get* 유형의 호출) 기반 SOAP 작업을 받는 경우 현재는 이를 캐시할 수 있는 방법이 없습니다.그러나 REST를 사용하여 이와 동일한 작업을 구현하려는 경우 위에서 언급한 것처럼 데이터(비즈니스 컨텍스트에 따라 다름)가 캐시될 가능성이 있습니다.SOAP는 작업에 POST를 사용하기 때문에 서버 측에서 정보를 캐시할 수 없습니다.

SOAP는 확실히 느립니다.페이로드가 상당히 크기 때문에 조립, 전송, 구문 분석, 검증 및 처리 속도가 느려집니다.

벤치마킹 질문에 대한 답변은 모르지만 SOAP 형식에 대해 알고 있는 것은 '예'입니다. 오버헤드가 있지만 요청마다 오버헤드가 증가하지 않습니다.웹 서비스에 요소 1개를 전송한 경우 오버헤드 + 요소 구성 1개가 있고, 웹 서비스에 요소 1000개를 전송한 경우 오버헤드 + 요소 구성 1000개가 있습니다.XML 요청이 특정 작업에 맞게 형식화되었지만 요청의 모든 개별 인수 요소 형식이 동일하므로 오버헤드가 발생합니다.

반복 가능한 짧은 데이터 버스트(예: 500개 요소)를 고수한다면 속도는 허용될 것입니다.

여기서 주요 질문은 RPC와 SOAP를 어떻게 비교하는가입니다.

둘 다 작동하는 스텁 객체와 이 모든 것이 어떻게 처리되는지 실제로 알지 못한 채 다시 가져오는 기본/복잡한 데이터 유형을 가짐으로써 동일한 통신 추상화 접근 방식을 제공합니다.

저는 항상 (JSON-)RPC를 선호합니다. 왜냐하면

가볍다
모든 프로그래밍 언어에 대한 훌륭한 구현이 많이 있습니다.
학습/사용/생성이 간단합니다.
빠릅니다(특히 JSON의 경우)

SOAP를 사용해야 하는 이유가 있지만, 즉올바른 순서에 의존하는 대신 매개변수 이름 지정이 필요한 경우

이 stackoverflow에서 얻을 수 있는 자세한 내용 질문

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow