다행스럽게도 Go의 표준 라이브러리 기반으로 제가 구현한 라우터의 성능 이슈가 발견되어

과감히 제거하고, Fiber v3을 사용하는 걸로 변경하였습니다.

아울러 핸들러 부분의 코드를 이참에 좀 더 개선하여서 보다 나은 동작을 기대할 수 있게 되었습니다…!

다만, 예상과 달리 MySQL(Mariadb)가 끼어드는 리얼 월드에서는 Go언어의 성능이 Bun 대비 우세하진 않았습니다.

TSBOARD가 사용하는 여러 API들을 다양하게 테스트 해보면, 동등에서 약 열세라고 볼 수 있네요.

Go가 CPU 사용량은 더 많고, 메모리는 Bun 대비 더 적게 사용하고 있습니다.

아래 간단히 상대적으로 비교해 보겠습니다.

(여기서도 비슷한 결과를 보실 수 있습니다: https://medium.com/deno-the-complete-reference/bun-vs-go-native-hello-world-performance-006791174df2)

물론 절대적인 기준으로 한 건 아니고 어디까지나 TSBOARD에서 부하가 가장 많은 몇몇 라우터들 기준으로

hey 라는 도구를 이용해서 조금 가혹하게 (-n 3000 -c 100) 진행한 것 입니다만, 이 정도로 테스트 해봤으면

이제 어느 정도 감은 잡은 것 같습니다.

예상외로 Bun과 Elysia, 그리고 mysql2의 조합이 정말 찰떡이었구나 하는 점을 느꼈고

처음에 TSBOARD 프로젝트를 시작할 때 신중하게 골랐던 이 스택이 황금 스택이었음을 깨닫습니다.

그래서… 아깝지만 Go 언어로 재작성한 백엔드를 여기서 포기하고 그냥 기존 스택을 유지하면서 개발할까?

아니면 새로 재작성한 백엔드의 다른 장점들을 살려서 나아갈까? 하는 고민이 남았네요.

처음에는 Bun으로 다시 돌아가려고 했는데 (Fiber v3 사용 전), 지금은 성능 측면에선 (제 기준) 10% 약 열세를

감안하더라도 별도의 런타임에 의존하지 않는 것이나, 낮은 메모리 사용량, 추가 성능 향상의 여지가 보여서

우선은 계속 진행해 나가고자 합니다.

추후 블로그에 좀 더 상세한 테스트 내용을 공유드릴 수 있도록 하겠습니다…!

이제 TSBOARD : GOAPI 백엔드 프로젝트는 아래의 과정이 남았습니다.

1) 관리화면용 백엔드 재작성

2) TSBOARD (재)설치용 백엔드 재작성

3) 응답성 개선을 위한 추가 튜닝

최대한 이번 달 안으로 Go언어로의 전환을 마무리 하겠습니다!