Netty 대 Apache MINA

Question

둘 다 거의 동일한 기능을 제공합니다. 고성능 TCP 서버를 개발하려면 어느 것을 선택해야합니까? 찬성이 무엇입니까 &?

참조 링크 :

Apache MINA (source)

Netty (source)

Answer 1

MINA와 Netty는 비슷한 야망을 가지고 있지만 실제로는 매우 다르므로 선택 사항을 신중하게 고려해야합니다. 우리는 MINA와의 많은 경험을했고 Netty로 놀 기회가 있었기 때문에 운이 좋았습니다. 우리는 특히 더 깔끔한 API와 더 나은 문서를 좋아했습니다. 종이에서도 성능이 더 좋아 보였습니다. 더 중요한 것은 우리는 Trustin Lee가 우리가 갖고있는 질문에 답할 수 있다는 것을 알고 있었고 확실히 그렇게했습니다.

Netty에서 모든 것을 쉽게 발견했습니다. 기간. 우리가 MINA에서 이미 가지고있는 것과 동일한 기능을 다시 구현하려고 시도했지만 처음부터 그렇게했습니다. 훌륭한 문서와 예제를 따르면 훨씬 더 많은 코드로 더 많은 기능을 사용할 수있게되었습니다.

Netty Pipeline이 우리를 위해 더 잘 작동했습니다. 그것은 MINA보다 더 간단합니다. 모든 것이 핸들러이고, 업스트림 이벤트, 다운 스트림 이벤트를 처리할지 아니면 더 낮은 레벨의 물건을 사용할지 결정하는 것은 당신에게 달려 있습니다. "재생"디코더에서 바이트를 맴돌아 보는 것은 거의 즐거움이었습니다. 즉석에서 파이프 라인을 쉽게 재구성 할 수 있다는 것도 매우 좋았습니다.

하지만 Netty의 별 매력 인 imho는 "coverage of one"으로 파이프 라인 처리기를 만드는 기능입니다. 이 설명서의 내용을 이미 읽었을 수도 있지만 본질적으로 코드의 한 줄에 상태를 제공합니다. 어지럽히 지 않고, 세션 맵, 동기화 및 그런 것들이 없었기 때문에, 우리는 단순히 일반 변수 ("username")를 선언하고 사용할 수있었습니다.

그러나 우리는로드 블록을 쳤습니다. 우리는 이미 우리의 응용 프로그램 프로토콜이 TCP/IP, HTTP 및 UDP를 통해 실행되는 MINA에서 멀티 프로토콜 서버를 사용했습니다. Netty로 전환했을 때 몇 분 만에 SSL과 HTTPS를 목록에 추가했습니다! 지금까지는 그렇게 좋았지 만, UDP가되었을 때 우리는 우리가 빠져 나간 것을 깨달았습니다. MINA는 UDP를 "연결된"프로토콜로 취급 할 수있어서 매우 좋았습니다. Netty에는 그러한 추상화가 없습니다. UDP는 비 연결이며 Netty는이를 그대로 취급합니다. Netty는 MINA보다 낮은 수준에서 UDP의 비 연결형 특성을 더 많이 나타냅니다. MINA가 제공하는 더 높은 수준의 추상화로는 불가능하지만 우리가 의존했던 것보다 Netty에서 UDP로 할 수있는 일이 있습니다.

"연결된 UDP"래퍼 또는 다른 것을 추가하는 것은 그리 간단하지 않습니다. 주어진 시간 제약과 Trustin의 조언에 따르면 가장 좋은 방법은 Netty에서 자체 전송 공급자를 구현하는 것이 었습니다. 빠른 속도는 아니므로 결국 Netty를 포기해야했습니다.

그래서 이들 간의 차이점을 살펴보고 까다로운 기능이 예상대로 작동하는지 테스트 할 수있는 단계로 빠르게 이동하십시오. Netty가 그 일을 할 것이라 고 확신한다면 MINA를 통해 Netty와 함께 가기를 망설이지 않을 것입니다. MINA에서 Netty로 이동하는 경우에도 마찬가지입니다. 그러나 두 API가 실제로 상당히 다르다는 점에 유의해야하며 Netty의 가상 재 작성을 고려해야합니다. 후회하지 않아도됩니다.

Answer 2

의 Netty 사이트에 당신이 어떤 성능을 reports 찾을 수 있습니다. 예상대로 :-) 그들은 Netty를 최고의 성능을 가진 프레임 워크로 지적합니다.

나는 인 Netty를 사용하지 않습니다,하지만 난 이미 TCP 프로토콜을 구현하는 MINA를 사용했다. 인코딩과 디코딩의 구현은 쉽지만 상태 머신의 구현은 쉽지 않았습니다. MINA는 상태 시스템을 구현할 때 도움이되는 몇 가지 수업을 제공하지만, 사용하기가 다소 어려웠습니다. 결국 우리는 MINA를 버리고 처음부터 프로토콜을 구현하기로 결정했으며 놀랍게도 더 빠른 서버로 끝났습니다.

Answer 3

저는 MINA를 사용하여 서버와 같은 작은 http를 구축했습니다. 지금까지 실행 해 본 가장 큰 문제는 다음과 같습니다.

1. "요청"과 "응답"이 메모리에 저장됩니다. 이것은 내가 선택한 프로토콜이 http이기 때문에 유일한 문제입니다. 그러나이 문제를 해결하기 위해 자신 만의 프로토콜을 사용할 수 있습니다.
2. 대용량 파일을 제공하려는 경우 디스크에서 스트림을 제공하는 옵션이 없습니다. 당신이 때 알고 다음 분산 작업 시스템의 일종을 구현하기 위해 선택하는 경우
   1. 가 연결
   2. 을 많이 처리 할 수 ​​있습니다 다시 자신의 프로토콜 그것에 대해

   좋은 점을 구현하여 해결할 수 있습니다 노드 중 하나가 중단되고 연결이 끊어지면 다른 노드에서 작업을 다시 시작하는 데 유용합니다.

Answer 4

MINA와의 Netty는 초기 설계와 같은 저자에 의해 구축되었다. 그래서 서로가 너무 비슷합니다. MINA는 약간 더 높은 수준으로 디자인되었으며, Netty는 조금 더 빠릅니다. 전혀 차이가 없다고 생각합니다. 기본 개념은 동일합니다.

Answer 5

MINA는 복잡성과 상대적으로 낮은 성능의 비용으로 더 아웃 - 오브 - 박스 기능을 가지고 있습니다. 이러한 기능 중 일부는 사용자가 필요하지 않더라도 제거하기에 너무 긴밀하게 코어에 통합되었습니다. Netty에서는 MINA의 장점을 간직하면서 이러한 디자인 문제를 해결하려고 노력했습니다.

는 현재 MINA에서 사용할 수있는 대부분의 기능의 Netty에서도 사용할 수 있습니다. 내 생각에 Netty는 MINA를 처음부터 다시 작성하고 알려진 문제를 해결하려고 시도한 결과이므로 Netty는 더 명확하고 문서화 된 API를 제공합니다. 필수 기능이 누락 된 경우 포럼에 제안을 게시하십시오. 귀하의 우려를 해소하게되어 기쁩니다.

이 인 Netty 빠른 개발주기를 가지고 있음을주의하는 것이 중요하다. 간단하게 최근 릴리스의 출시 날짜를 확인하십시오. 또한 MINA 팀이 MINA 3을 다시 작성하여 API 호환성을 완전히 깨뜨릴 것을 고려해야합니다.

Answer 6

성능 테스트 2 하나는 Netty (netty-protobuf-rpc)를 기반으로하고 다른 하나는 mina (protobuf-mina-rpc)를 기반으로하는 2 개의 "Google Protobuffer RPC"구현입니다. Netty는 Netty 웹 사이트의 전체 성능 요구를 뒷받침하는 모든 메시지 크기에 대해 지속적으로 더 빠르게 (+ 10 %) 빨라졌습니다. RPC 라이브러리를 사용할 때 코드의 효율성을 극대화하고자하므로 Netty를 기반으로 protobuf-rpc-pro을 작성했습니다. 이전에 MINA를 사용했지만 2.0 문서에 대한 문서에 큰 구멍이 있으며 API 역 호환성이 큰 차이가 없었습니다.

Answer 7

나는 Netty를 선호합니다.

트위터도 새로운 검색 시스템을 구축하기 위해 Netty를 선택했으며 최대 3 배 빨라졌습니다.

참조 : 그것은 깨끗한 API, 더 나은 문서를 가지고 있기 때문에 Twitter Search is Now 3x Faster

우리는 미나와 부두 등의 다른 경쟁사의 일부 동안의 Netty를 선택하고, 더 중요한 것은, 트위터에서 다른 여러 프로젝트를 사용하고 있기 때문에 이 프레임 워크.