Nice programing

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

nicepro 2020. 11. 8. 11:03
반응형

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


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

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

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

업데이트 : 나는 여전히 이것에 매우 관심이 있습니다. 누군가가 더 이상의 벤치 마크를 수행했다면 저에게 알려주십시오. 또한 압축 된 JSON이 Thrift / Protocol Buffers보다 비슷하거나 더 나은 성능을 보여주는 매우 흥미로운 벤치 마크 이므로이 질문에도 JSON을 던지고 있습니다.


thrift-protobuf-compare 프로젝트 위키 에서 최신 비교를 볼 수 있습니다 . 다른 많은 직렬화 라이브러리가 포함됩니다.


protobuf와 thrift를 비교하는 thrift-protobuf-compare라는 오픈 소스 프로젝트 에서 코드를 작성하는 중 입니다. 지금은 직렬화 측면을 거의 다루지 않지만 더 다루려고합니다. 결과 ( ThriftProtobuf의 경우 )는 내 블로그에서 논의되며, 얻을 때 더 추가하겠습니다. API, 설명 언어 및 생성 된 코드를 비교하기 위해 코드를 볼 수 있습니다. 좀 더 둥근 비교를 할 수 있도록 기여해 주시면 기쁩니다.


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


다른 데이터 형식 (xml, json, 기본 개체 직렬화, hessian, 독점 형식 하나)과 데이터 바인딩 작업 (읽기 및 쓰기 모두)을위한 라이브러리 (jaxb, 빠른 정보 집합, 손으로 쓴)로 PB의 성능을 테스트했습니다. 그러나 중고품의 형식은 포함되지 않았습니다. 여러 변환기 (예 : xml)가있는 형식의 성능은 매우 느림에서 매우 빠른 속도까지 매우 큰 차이를 보였습니다. 저자의 주장과인지 된 성과 간의 상관 관계는 다소 약했습니다. 특히 강력한 주장을 한 패키지의 경우 특히 그렇습니다.

그만한 가치가 있기 때문에 PB 성능이 약간 과장된 것으로 나타났습니다 (일반적으로 작성자가 아니라 작성자 만 아는 다른 사람). 기본 설정으로는 가장 빠른 텍스트 xml 대안을 능가하지 못했습니다. 최적화 모드 (이것이 기본값이 아닌 이유는 무엇입니까?)를 사용하면 가장 빠른 JSON 패키지와 비교할 수있는 조금 더 빠릅니다. Hessian은 다소 빠르고 텍스트 json이었습니다. Properietary 바이너리 형식 (이름 없음, 회사 내부)이 가장 느 렸습니다. 자바 객체 직렬화는 더 큰 메시지에 대해서는 빠르며, 작은 객체에 대해서는 빠릅니다 (즉, 높은 고정 작업 당 노버 헤드). PB를 사용하면 메시지 크기가 콤팩트했지만해야 할 모든 절충 사항을 감안할 때 (데이터 자체 설명이 아님 : 스키마를 잃으면 데이터를 잃게됩니다. 물론 색인과 값 유형이 있지만 보유한 것 원하는 경우 필드 이름으로 역 엔지니어링),

제 생각에는 (a) 구현이 (데이터 형식의) 사양보다 더 중요한 경우가 많고, (b) 종단 간, 동급 최강 (다른 형식의 경우) 간의 차이는 일반적으로 선택. 즉, 가장 많이 사용하는 형식 + API / lib / 프레임 워크를 선택하고 (또는 최상의 도구 지원을 제공하는) 최상의 구현을 찾은 다음 충분히 빠르게 작동하는지 확인하는 것이 좋습니다. 그렇지 않은 경우에만 차선책을 고려하십시오.

추신. 여기에 EJB3이 무엇인지 확실하지 않습니다. 자바 직렬화에 대한 평범한가?


PB에 대한 "해야 할 일"목록의 맨 위에있는 것 중 하나는 Google의 내부 프로토콜 버퍼 성능 벤치 마크를 포팅하는 것입니다. 대부분 기밀 메시지 형식을 완전히 평범한 형식으로 전환 한 다음 동일한 작업을 수행하는 경우입니다. 자료.

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

즉, 아직 데이터가 없습니다.하지만 앞으로 몇 주 안에 ...


원시 순 성능이 목표라면 IIOP를 능가하는 것은 없습니다 (RMI / IIOP 참조). 가능한 최소 풋 프린트-이진 데이터 만, 마크 업 없음. 직렬화 / 역 직렬화도 매우 빠릅니다.

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

하지만 성능이 유일한 요구 사항 은 아니라고 생각합니다 .


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

  • Thrift는 작은 데이터 (작업 인수로 기본 유형)에서 매우 효율적입니다.
  • Thrifts 전송은 중대형 데이터 (구조 및> 복합 유형> 1KB)가있는 CORBA만큼 효율적이지 않습니다.

성능과 관련이없는 또 다른 이상한 제한은 Thrift가 구조체로 몇 개의 값만 반환하도록 제한되어 있다는 것입니다. 성능과 같이 확실히 개선 될 수 있습니다.

Thrift IDL이 CORBA IDL과 거의 일치한다는 것이 흥미 롭습니다. 저는 Thrift를 사용하지 않았고, 특히 작은 메시지에 대해 흥미로워 보이며 디자인 목표 중 하나는 덜 성가신 설치를위한 것이기 때문에 Thrift의 다른 장점입니다. 즉, CORBA는 나쁜 랩 을 가지고 있으며 예를 들어 설치 및 사용이 쉬운 Python에 대한 바인딩이있는 omniORB 와 같은 우수한 구현이 많이 있습니다.

편집 됨 : Thrift 및 CORBA 링크는 더 이상 유효하지 않지만 CERN에서 또 다른 유용한 문서를 찾았습니다. 그들은 CORBA 시스템의 대체품을 평가하고 Thrift평가 하는 동안 결국 ZeroMQ를 사용했습니다. Thrift는 성능 테스트에서 9000 msg / sec vs. 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로 시도하지 않습니다.

풀 리퀘스트를 통해 프로젝트를 완료 할 수 있습니다 (수정 또는 기타 결과).

참고 URL : https://stackoverflow.com/questions/296650/performance-comparison-of-thrift-protocol-buffers-json-ejb-other

반응형