C++Builder  |  Delphi  |  FireMonkey  |  C/C++  |  Free Pascal  |  Firebird
볼랜드포럼 BorlandForum
 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지
분야별 포럼
C++빌더
델파이
파이어몽키
C/C++
프리파스칼
파이어버드
볼랜드포럼 홈
헤드라인 뉴스
IT 뉴스
공지사항
자유게시판
해피 브레이크
공동 프로젝트
구인/구직
회원 장터
건의사항
운영진 게시판
회원 메뉴
북마크
볼랜드포럼 광고 모집

자유게시판
세상 살아가는 이야기들을 나누는 사랑방입니다.
[24504] DataSnap의 처참한 성능...
박지훈.임프 [cbuilder] 13519 읽음    2014-02-27 02:38


DataSnap의 처참한 성능과 안정성에 대하여, 2012년 11월에 Roberto Schneiders가 처음 이슈를 일으켰던 글.
http://robertocschneiders.wordpress.com/2012/11/22/datasnap-analysis-based-on-speed-stability-tests/

새 DataSnap이 성능이 많이 좋아졌다는 말도 있었는데, 이 결과 대로라면 돌아볼 필요조차 없는 그냥 쓰레기 수준. DataSnap에 그닥 신뢰가 가지 않아 했지만, 그래도 이건 믿기지 않는 수준이라 더 자세히 찾아봄.

결론은 역시나인 듯. 이 글에 자극받은 다른 여러 개발자들이 비슷한 테스트를 시도했는데 정도 차이는 있지만 비슷비슷한 결과. Delphi 기반의 모든 3티어 중에서 DataSnap이 성능, 안정성, 확장성 모두 최악. 그냥 낮은 정도가 아니라 바닥 수준.

이 글과 비슷한 다른 테스트들의 댓글들을 읽어보면 알 수 있겠지만, David I와 Marco Cantu 등 엠바카데로 가이들이 진화를 시도했고, 다른 몇몇 개발자들이 테스트의 자잘한 오류를 지적하며 반박했으나 몇차례의 재 테스트 끝에 깨갱. 반박도 변명도 포기. 뒤이어 지적된 개선점들을 적용해서 두번째 테스트를 진행했으나 결과는 거기서 거기, 모든 논란은 평정됨. 결론은 DataSnap은 쓰레기.

http://robertocschneiders.wordpress.com/2013/01/09/datasnap-analysis-based-on-speed-stability-tests-part-2/
http://andremussche.blogspot.kr/2013/01/datasnap-ro-rtc-mormot-wcf-node-speed.html
http://mikejustin.wordpress.com/2012/11/26/datasnap-speed-and-stability-tests/

3티어 프레임워크 성능에 대해 정말 관심이 있다면 위의 글들을 다 읽어볼 필요가 있음. (여러개 더 있지만 그중 객관적인 데이터가 첨부되고 중요한 결과들만 모은 것임.)

요약하자면... DataSnap은 간단하고 소규모, 부하가 아주 낮은 기업 서비스 구축에나 사용 가능. 웬만한 성능 차이라면 눈 딱 감고 초고성능 하드웨어로 때워버릴 수도 있겠지만 이렇게 엄청난 격차는 5년, 10년 이상의 세대 차이가 나는 머신 성능으로도 때울 수가 없음. 더욱이 부하가 집중되면 아예 뻗어버리는 황당한 안정성은 무엇으로도 커버가 불가능.

여러 개발자들이 테스트한 결과들을 종합해서 여러 기술들의 성능을 비교해보면, 대충 다음과 같은 순위가 나오는 듯. (DataSnap도 끼워넣기는 했지만, 그래도 의미 있는 경쟁이라 할 수 있는 1~6위까지와는 달리 처참한 수준)

1. mORMot (Delphi)
2. RTC (Delphi)
3. WCF (.NET)
4. RemObjects (Delphi) (아마도 kbmMW도 비슷?)
5. Jersey/Grizzly (Java)
6. Node.js
7. DataSnap (Delphi)

덧붙여, mORMot는 성능과 scalability에서도 최고이지만, 낮은 메모리 소요 면에서도 뛰어남. 더욱이 완전히 무료! RemObjects와 kbmMW가 비슷한 수준인 이유는, 같은 상용 프레임워크로서 비슷한 시기 동안 함께 경쟁해오며 비슷한 기반 기술들을 도입했기 때문으로 보임.

도대체 엠바카데로는 왜 DataSnap같은 쓰레기를 디폴트 3티어 프레임워크로 제공하고, 그것도 모자라 DataSnap의 성능이 아주 준수한 듯이 내세워서 델파이 개발자들이 자바나 닷넷 등 다른 경쟁 기술 개발자들에게 개망신을 당하게 만들고 있는 걸까.

이런 정도라면 DataSnap은 그냥 deprecated 처리해버리고 mORMot나 RTC, RemObjects, kbmMW 등 서드파티 라이브러리를 추천하는 선에서 물러서는 것이 델파이 개발자들 전체를 위해서도, 엠바카데로 스스로를 위해서도 훨씬 나을텐데. 더욱이 모바일에 올인하느라 DataSnap에는 제대로 손도 안대고 있으면서.
박지훈.임프 [cbuilder]   2014-02-27 02:44 X
이런 결과 덕분에... 내게 최고의 만족을 줬던 kbmMW 대신 mORMot를 내 프레임워크의 기반 3티어 프레임워크로 교체할지를 심각하게 고민하는 중.

근데 대충 살펴봤는데 mORMot는 공부할 게 너무 어마어마한 수준... 유닛은 얼마 안되는데 도큐먼트만 1300페이지가 넘고, 적용된 아키텍처만 해도 ORM부터 MVC, SOA, DDD까지. 공부할 꺼리의 대향연.
박지훈.임프 [cbuilder]   2014-02-27 03:51 X
위 테스트들은 모두 XE3 버전의 DataSnap 기준인데요. 그럼 현재의 최신 버전인 XE5에서는 많이 나아지지 않았을까 기대해볼 수도 있겠지만...

XE4와 XE5의 문서를 봐도, 모바일 지원 추가 관련 외에는 DataSnap에 대한 언급 자체가 별로 없고요.
혹시나 해서 대충이나마 XE5 VCL의 DataSnap 유닛들을 XE3와 diff 해봤는데, 역시나 성능이나 안정성 관련의 개선은 거의 없어보이네요.
civilian [civilian]   2014-02-27 10:38 X
페북에도 썼지만...

Hello, World 반복해서 요청하는 것으로는 정상적인 테스트라 할 수 없음.
하다못해 데이터베이스에서 랜덤한 쿼리를 수행해서 수 ~ 수만 레코드를 요청하는
테스트 정도는 되어야 미들웨어에 대한 테스트라 할 수 있지 않을까?
박지훈.임프 [cbuilder]   2014-02-27 11:21 X
예전에 성능 테스들을 해본 경험으로는, 기본 상태에서 성능 차이가 저 정도로 벌어지면 DB 데이터 조회의 경우에도 역시 성능 격차가 수준으로 벌어지죠. 더욱이 이 문제는 여러가지 상황을 종합해볼 때 DataSnap의 아키텍처상의 문제가 가장 의심스러운 상황이기 때문에 더 그래요.
박지훈.임프 [cbuilder]   2014-02-27 12:06 X
페북 글에 썼던 댓글 인용,

요약하자면, 문제의 핵심은 Indy보다는 DataSnap의 기본 아키텍처 설계상의 문제로 보임.

1. Indy가 요인들 중 하나로 보이지만, 다른 기술들에서는 Indy를 쓴 경우에도 synapse나 DxSock과 그렇게 큰 차이까지는 나지 않음. 나도 실제 테스트에서 경험했던 부분.

2. 다른 기술들에서는 ScaleMM2를 적용하면 속도가 비약적으로 빨라지는데, DataSnap의 경우엔 ScaleMM2를 적용해도 역시 바닥 수준.
박지훈.임프 [cbuilder]   2014-02-27 15:10 X
DataSnap의 낮은 성능 관련한 글들 때문에, 내 개발 프레임워크의 하위 멀티티어로 mORMot를 도입하는 문제를 심각하게 고민했는데... 하루 넘게 치열하게 고민한 끝에, 그냥 kbmMW로 돌아가기로.

일단 mORMot로 전환할 때, 당장 내가 하부 전체를 뜯어고치는 개발 부담이 너무 크다. 그보다 더 심각한 문제는, 교육의 문제. SI 개발 프레임워크의 특성상 화면개발자들에게 교육이 필수인데 mORMot의 복잡한 아키텍처와 방법론을 다 교육시키려다간 교육에만 몇달이 흘러갈 듯. 최소 1년 이상의 프로젝트가 아니라면 비현실적.

kbmMW는 기본적으로 전통적인 델파이의 방식을 따르기 때문에 교육부담이 훨씬 적다. kbmMW의 개발 구조도 꽤 복잡하긴 하지만 제대로 래핑하면 수많은 아티클들을 동원해서 설명해야 할 DataSnap보다 화면개발이 쉬워지는 것은 물론, 암만 길어도 불과 며칠이면 교육을 끝내고 개발에 착수시킬 수 있다.

프로젝트에서 화면개발자들의 러닝 커브의 문제는 SI에서 절대 무시할 수 없는 심각한 문제. 성능을 10% 정도 올리자고 덤빌 수 있는 리스크가 아님. 더욱이 내 프레임워크의 주력 목표시장은 델파이 기반 멀티티어가 아니다.

물론... 무엇보다 내가 이미 익숙하고 내 프레임워크에 잘 붙어서 개발생산성이나 성능이나 여러모로 검증된 것이라는 장점도 무시할 수 없겠고.

머 한마디로 요약하자면... 귀찮다는 것. ㅋㅋㅋㅋ;;
양병규 [bkyang]   2014-02-27 15:46 X

지훈님이............... 보고싶다는.............. ^^ ........... -- .......... ㅠㅠ ......... 세월이 빨리가니.. 그만큼 만남의 간격도 길어지는 듯..
박지훈.임프 [cbuilder]   2014-02-27 20:46 X
ㅎㅎㅎㅎㅎ;;
저야말로 양병규님이 무쟈게 보고 싶습니다~
요즘 어디쪽에 계세요? 시간날 때 제가 한번 놀러가게요~ ^^
양병규 [bkyang]   2014-02-28 14:53 X

요즘 수서 사무실로 출근합니다.
일주일에 2~3일 정도요.
나머지 시간은 서울성모병원이나 구로에 한 업체에 가기도 하구요.

오늘은 미세먼지가 없을거라더니 아주 없진 않네요
그래도 다니기 훨 낫군요.
즐거운 주말들 되세요.
델초보 [desert4]   2014-03-03 09:29 X
지훈님 항상 좋은 정보 감사합니다.
kbmMW 무료입니까?
혹시 유료이면 비용이 어떻게 되는지?
사이트는 어떻게 되는지 부탁드립니다.
티지 [tg529]   2014-03-03 11:31 X
Datasnap 시원하게 까발려주셔서 감사합니다..
XE5에서 엄한 테스트를 또 할 필요없이 ..소잡는 도끼는 아니어도 닭잡는 칼정도 일까요?
새로 진행해야될 업무환경을 위해 이것저것 알아보고 있는데 기냥 Drop수준?
지난번 오프모임때 좀 아쉬웠는데. 언제한번 뵈용..
김모씨 [testcode]   2014-03-04 00:25 X
이미 엔터프라이즈 환경에서 무시되는 프레임워크... 안타까운거죠 기술의 한계성.
박지훈.임프 [cbuilder]   2014-03-04 08:50 X
델초보님,
kbmMW는 유료 라이브러리구요. 엔터프라이즈가 638달러, 프로페셔널이 278달러입니다.
2005년에 프레임워크 개발할 때 처음 구입했었는데 이번에 프레임워크 재개발을 위해 며칠 전에 다시 구입했네요. ^^
사이트는 아래와 같습니다.
http://www.components4programmers.com/
건비 [epilogs]   2014-05-08 14:37 X
Datasnap을 사용할 일이 없어 제꼈다가 사용할 일이 생겨서 기웃거리고 있습니다.
Delphi MiddleWare분야는 완전 무지해서 몇 가지 좀 여쭙겠습니다.

원기사에 기사 작성자가 달아놓은 덧글을 보니 이런 내용이 있던데요.

'My tests were only in REST servers, hard to say something about the other servers. However, I believe that the datasnap TCP/IP server suffer from similar problems, especially problems related to performance, who I’ll show in the next post in REST servers.'

'REST기반 서버 테스트 결과물이기는 하지만 TCP/IP 기반 서비스도 비슷한 결과일 것이다'라는 의미로 보이는데..
정말 TCP/IP 기반에서도 성능이나 안정성이 사용 못할 정도일까요..?

저는 어차피 MiddleWare를 처음 구축하는 단계라서 mORMot 를 선택해도 될 듯 한데 DataSnap보다 사용하기는 까다로운지요.
(mORMot 가 DataSnap용 클라이언트 콤포넌트와 호환되는지 여부나 Firemonkey를 지원하는지 등등)


+ -

관련 글 리스트
24504 DataSnap의 처참한 성능... 박지훈.임프 13519 2014/02/27
Google
Copyright © 1999-2015, borlandforum.com. All right reserved.