Thrift, 프로토콜 버퍼, JSON, EJB 등의 성능 비교?

https://stackoverflow.com/questions/296650

08-07-2019
|

문제

우리는 전송/프로토콜 솔루션을 조사하고 있으며 다양한 성능 테스트를 수행하려고 했기 때문에 커뮤니티에서 이미 이 작업을 수행했는지 확인해야 한다고 생각했습니다.

Linux의 EJB3, Thrift 및 프로토콜 버퍼를 비교하여 다양한 메시지 크기에 대한 직렬화/역직렬화뿐만 아니라 간단한 에코 서비스에 대한 서버 성능 테스트를 수행한 사람이 있습니까?

주로 언어는 Java, C/C++, Python 및 PHP입니다.

업데이트:나는 여전히 이것에 매우 관심이 있습니다. 누구든지 추가 벤치마크를 수행한 경우 알려 주시기 바랍니다.또한 매우 흥미로운 벤치마크 결과가 나와 있습니다. Thrift/프로토콜 버퍼와 비슷하거나 더 나은 성능을 발휘하는 압축 JSON, 그래서 이 질문에도 JSON을 던지고 있습니다.

해결책

최신 비교는 여기에서 확인할 수 있습니다. 절약-protobuf-비교 프로젝트 위키.여기에는 다른 많은 직렬화 라이브러리가 포함되어 있습니다.

다른 팁

나는 몇 가지 코드를 작성하는 중입니다. thrift-protobuf-compare라는 오픈 소스 프로젝트 protobuf와 thrift를 비교합니다.지금은 직렬화 측면을 거의 다루지 않지만 더 많은 내용을 다루려고 합니다.결과(에 대한 절약 그리고 프로토부프)에 대해서는 내 블로그에서 논의하고 있으며, 더 많은 내용을 추가하게 되면 추가하겠습니다.API, 설명 언어 및 생성된 코드를 비교하기 위해 코드를 볼 수 있습니다.보다 균형 잡힌 비교를 달성하는 데 기여하게 되어 기쁩니다.

이 질문에 관심이 있을 수 있습니다. "Thrift와 프로토콜 버퍼의 가장 큰 차이점은 무엇입니까?"

데이터 바인딩 작업(읽기 및 쓰기 모두)을 위해 다양한 다른 데이터 형식(xml, json, 기본 객체 직렬화, 헤시안, 하나의 독점 형식)과 라이브러리(jaxb, fast infoset, hand-writing)를 사용하여 PB의 성능을 테스트했습니다. 그러나 Thrift의 형식은 포함되지 않았습니다.여러 변환기(예: xml)가 있는 형식의 성능은 매우 느린 것부터 매우 빠른 것까지 매우 높은 차이를 보였습니다.저자의 주장과 인지된 성과 사이의 상관관계는 다소 약했습니다.특히 가장 거친 주장을 한 패키지의 경우 더욱 그렇습니다.

그만한 가치가 있기 때문에 나는 PB 성능이 약간 과장된 것으로 나타났습니다(대개 작성자가 아니라 작성자만 아는 다른 사람들이 아님).기본 설정으로는 가장 빠른 텍스트 XML 대안을 능가하지 못했습니다.최적화 모드(기본값이 아닌 이유)를 사용하면 가장 빠른 JSON 패키지와 비교할 수 있을 정도로 조금 더 빨라졌습니다.Hessian은 다소 빨랐고, 텍스트 형식의 json도 있었습니다.독점 바이너리 형식(여기에는 이름이 없습니다. 회사 내부용임)이 가장 느렸습니다.Java 객체 직렬화는 큰 메시지의 경우 빠르며, 작은 객체(예:높은 고정 작업당 nohead).PB를 사용하면 메시지 크기가 작았지만 모든 절충안을 고려하여 수행해야 합니다(데이터는 자체 설명이 아닙니다.스키마를 잃으면 데이터도 잃습니다.물론 인덱스와 값 유형이 있지만 원하는 경우 리버스 엔지니어링을 통해 필드 이름으로 돌아가는 것) 개인적으로 특정 사용 사례(인터페이스/형식이 있는 크기에 민감하고 밀접하게 결합된 시스템)에만 선택합니다. 결코 (또는 아주 아주 드물게) 변하지 않습니다.

이에 대한 내 의견은 (a) 구현이 (데이터 형식의) 사양보다 더 중요한 경우가 많다는 것입니다. (b) 종단 간, 동종 최고 수준(다른 형식에 대한) 간의 차이는 일반적으로 다음을 지시할 만큼 크지 않습니다. 선택.즉, 가장 많이 사용하고 싶은(또는 최고의 도구 지원이 있는) 형식+API/lib/프레임워크를 선택하고, 최상의 구현을 찾고, 그것이 충분히 빠르게 작동하는지 확인하는 것이 더 나을 수 있습니다.그렇지 않다면 (그리고 오직!) 차선책을 고려하십시오.

추신.여기서 EJB3가 무엇인지 잘 모르겠습니다.어쩌면 단순한 Java 직렬화일까요?

PB에 대한 내 "할 일" 목록의 맨 위에 있는 것 중 하나는 Google의 내부 프로토콜 버퍼 성능 벤치마크를 이식하는 것입니다. 이는 대부분 기밀 메시지 형식을 가져와 완전히 평범한 형식으로 바꾸는 경우입니다. 자료.

이 작업이 완료되면 Thrift에서 동일한 메시지를 작성한 다음 성능을 비교할 수 있다고 생각합니다.

즉, 아직 데이터가 없습니다. 하지만 앞으로 몇 주 안에 데이터가 나올 것으로 예상됩니다.

원시 순 성능이 목표라면 IIOP를 능가하는 것은 없습니다(RMI/IIOP 참조).가능한 가장 작은 공간 -- 바이너리 데이터만 있고 마크업은 전혀 없습니다.직렬화/역직렬화도 매우 빠릅니다.

IIOP(CORBA)이므로 거의 모든 언어에 바인딩이 있습니다.

하지만 내 생각엔 성능은 그렇지 않은 것 같아. 오직 요건 맞죠?

IIOP에 대한 Vladimir의 주장을 뒷받침하기 위해 Thrift와 CORBA를 비교하므로 Google 벤치마크에 대한 추가 정보를 제공하는 흥미로운 성능 테스트가 있습니다.(performance_tidorb_vs_thrift_morfeo.pdf // 링크가 더 이상 유효하지 않음) 연구에서 인용하려면 :

중고품은 작은 데이터 (기본 유형으로 조작 인수)에서 매우 효율적입니다.

중고품 운송은 중간 데이터 및 대형 데이터 (구조 및> 복잡한 유형> 1 킬로바이트)를 갖는 CORBA만큼 효율적이지 않습니다.

성능과 관련이 없는 또 다른 이상한 제한은 Thrift가 구조체로 여러 값만 반환하도록 제한된다는 것입니다. 물론 성능과 마찬가지로 이 역시 확실히 향상될 수 있습니다.

Thrift IDL이 CORBA IDL과 밀접하게 일치한다는 점이 흥미롭습니다.저는 Thrift를 사용하지 않았습니다. 특히 작은 메시지의 경우 흥미로웠으며 디자인 목표 중 하나는 덜 번거로운 설치를 위한 것이었으므로 이것이 Thrift의 또 다른 장점입니다.그렇긴 하지만, CORBA는 평판이 나쁘고 다음과 같은 훌륭한 구현이 많이 있습니다. 옴니ORB 예를 들어, 설치 및 사용이 쉬운 Python용 바인딩이 있습니다.

편집됨:Thrift 및 CORBA 링크는 더 이상 유효하지 않지만 CERN에서 또 다른 유용한 문서를 찾았습니다.그들은 CORBA 시스템의 교체품을 평가했으며, 중고품 평가, 그들은 결국 ZeroMQ를 선택했습니다.Thrift는 성능 테스트에서 9000 msg/sec로 가장 빠른 속도를 보였습니다.8000(ZeroMQ) 및 7000+ RDA(CORBA 기반)에서는 특히 다른 문제로 인해 Thrift를 더 이상 테스트하지 않기로 결정했습니다.

아직은 버그가 있는 미성숙한 제품입니다.

나는 내 업무를 위해 스프링 부트, 매퍼(수동, Dozer 및 MapStruct), Thrift, REST, SOAP 및 프로토콜 버퍼 통합에 대한 연구를 수행했습니다.

서버측: https://github.com/vlachenal/webservices-bench

클라이언트 측: https://github.com/vlachenal/webservices-bench-client

완성이 안되어 개인 컴퓨터에서 실행해봤습니다(테스트를 완료하려면 서버를 요청해야 합니다)...그러나 다음 사항에 대해서는 결과를 상담할 수 있습니다.

결론적으로 :

Thrift는 최고의 성능을 제공하며 사용하기 쉽습니다.
JSON 콘텐츠 유형을 사용하는 RESTful 웹 서비스는 Thrift 성능에 매우 가깝고 "사용 가능한 브라우저"이며 매우 우아합니다(내 관점에서는).
SOAP는 성능이 매우 낮지만 최상의 데이터 제어 기능을 제공합니다.
프로토콜 버퍼는 성능이 좋습니다 ...3명 동시통화까지...왜인지 모르겠습니다.사용하기가 매우 어렵습니다.나는 MapStruct와 함께 작동하도록 만드는 것을 (지금은) 포기하고 Dozer로는 시도하지 않습니다.

풀 요청(수정 사항 또는 기타 결과)을 통해 프로젝트를 완료할 수 있습니다.

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

제휴하지 않습니다 StackOverflow