go 용 web framework 벤치마크, 특징.

By SeukWon Kang

July 3, 2015

이전글 에 잠깐 언급했었던 http://kasw.blogspot.kr/2014/10/pythongolang-web-framework.html

go 용 web framework를 비교 테스트 해봤습니다.

그때 이후로 beego, revel , martini 이외에 딱히 떠오르는 것은 없는것 같아서 일단 평가가 별로인(듯한) martini는 빼고 ( 나중에 시간나면 한번 보고 싶긴 합니다. )

beego와 revel 만을 검토해 보았습니다.

사용한 기계의 spec

linux mint 17.1 cinnamon x64 Linux kasw-work 3.13.0-37-generic #64-Ubuntu SMP Mon Sep 22 21:28:38 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux i7-4790 3.6x4 4c8t ram 8G single channel ab -c 100 -n 500000 http://localhost:8080/

결과 요약

(절대적이지 않은 ) 성능 비교

beego

Requests per second: 16200.32 [#/sec] (mean)

revel

Requests per second: 24929.10 [#/sec] (mean)

둘다 전용의 command 인 bee 와 revel 를 사용해서 서비스 코드의 scaffolding을 만들어내고 ( ROR이나 django 처럼) 그 코드를 수정 해서 실행할수 있게 해줍니다.

beego 쪽이 좀더 본격적인 framework 같고 revel은 아직 더 만들어야 할부분이 남아 있는 느낌.

( ORM이 beego만 있고 revel은 없습니다. )

둘다 사용하기는 편해서 기존에 다른 프레임웍을 써본사람들은 금방 적응 가능할 것 같음.

다만 revel쪽이 좀 특이한데

기본 상태에서는 CPU를 하나만 사용합니다. ( 성능도 낮고 )

뭐가 문제인가 고민하다가 혹시나? 하고

init.go에

runtime.GOMAXPROCS(runtime.NumCPU())

를 적용했더니 전cpu사용 + 성능 향상 이란 황당한 상황이 발생 했습니다.

처음엔 어딘가에서 lock이 생기고 있나 했는데 그냥 golang의 기본 상태에서 실행 하고 있는 거였습니다.

그리고 revel은 app의 코드를 그냥 실행하는 것이 아니고 app코드를 파싱해서 tmp folder에 실행용 main.go를 생성 , 컴파일, 실행 시키는 형태를 사용합니다.

( 꼭 web2py를 사용하는 느낌이 들더군요. )

덕분에 마치 dynamic한 parameter name validation 을 하는것 같은 효과를 줍니다.

( 변수명 == url parameter 가 됩니다. )

당연히 속도는 꽤나 잘나올것 같은 구조 입니다.

둘다 공히 전용 command를 사용해서 개발 모드로 실행하면 코드가 수정될때 자동으로 반영 하는 기능을 가지고 있습니다.

template는 둘다 go언어의 기본 html/template package를 사용한다고 (메뉴얼에 ) 써 있습니다.

2015-07-04 추가. revel의 single cpu사용은 좀 불안한게 전체 cpu를 사용하면 뭔가 문제가 있어서 일부러 막아둔것인지 아니면 그냥 기본 상태로 둔것인지를 알수 없어서 불안하긴 합니다. ( 내부적인 data 공유 문제 등으로 1 cpu 만을 사용해야 한다던지 하는 이유라면 - 간단한 벤치로는 들어나지 않는 - 큰일이지요. )

그리고 구글+ 종민님께서 추천해주신 negroni과 gin은 (나중에 시간날때를 위한 ) 기록으로 여기에 적어 둡니다.