많은 방송국과 연결했을때의 성능 이슈

[sj-hub9796]

I9-14900KF CPU를 사용중인데, 최소 30개 이상(테스트했을때엔 70개)의 방송국과 연결하게될경우 CPU 사용량이 엄청나게 많아지면서 서비스가 다운됩니다.

[getCurrentThread]

이슈 오픈을 너무 늦게 확인하였네요.ㅜ 우선 많은 관심을 주셔서 감사합니다.
WebSocket 커넥션 관리와 메시지 처리, 버퍼와 관련된 부분에 대해서 최적화가 필요한 시점이라고 보여지긴 합니다.

현재는 웹소켓으로 많은 메시지가 들어오면 이로 인한 사용 버퍼를 gc로 처리하도록 하고,
사실상 각 방송국과의 연결을 개별 쓰레드로 처리하고 있어서...

어느 정도 최적화가 필요해보이는 시점이네요...

사실 그렇게 많은 사용량을 생각하지 않고 API를 작성한 터라,
최적화나 사용 인터페이스 수정을 해볼 생각이었긴 했습니다.

12월 말 또는 1월 초에 이 부분에 대한 업데이트를 진행할 예정이라,
그 동안 많은 관심 가져주시면 감사하겠습니다 🙏

[sj-hub9796]

현재 개인적으로 사용하기 위해서 cpu 전체 스레드 갯수의 절반만큼을 할당하여 전체 연결을 해당 스레드만으로 관리해봤는데, 최대 120개 이상의 방송국과 연결했을때에도 꽤 안정적으로 돌아가긴했습니다.

프로젝트가 정말 참신하고 기능 확장성이 좋아서 관심이 많았네요.

[getCurrentThread]

@sj-hub9796
안녕하세요. 이슈 남겨주신 내용에 대해 다양한 방향으로 수정 방안을 검토하느라 답변이 늦어진 점 죄송합니다.

언급하신 성능 관련 문제를 해결하기 위해 JDK17을 유지하면서 quasar 같은 라이브러리 사용이나
CompleteFuture 기반 비동기 방식을 검토했으나, JVM 단에서의 블로킹 작업 최적화가 필수적이라고 판단했습니다.

변경사항:

• JDK21의 가상 스레드(JEP 444) 기능을 도입하여 동시성 및 성능을 대폭 강화했습니다.
  (가상 스레드 관련 참고: 우아한기술블로그, NAVER D2)

추가 질문이나 피드백 있으시면 언제든지 말씀해주세요. 감사합니다.

[sj-hub9796]

@sj-hub9796 안녕하세요. 이슈 남겨주신 내용에 대해 다양한 방향으로 수정 방안을 검토하느라 답변이 늦어진 점 죄송합니다.

언급하신 성능 관련 문제를 해결하기 위해 JDK17을 유지하면서 quasar 같은 라이브러리 사용이나 CompleteFuture 기반 비동기 방식을 검토했으나, JVM 단에서의 블로킹 작업 최적화가 필수적이라고 판단했습니다.

변경사항:

• JDK21의 가상 스레드(JEP 444) 기능을 도입하여 동시성 및 성능을 대폭 강화했습니다.
  (가상 스레드 관련 참고: 우아한기술블로그, NAVER D2)

추가 질문이나 피드백 있으시면 언제든지 말씀해주세요. 감사합니다.

https://github.com/R2turnTrue/chzzk4j
다른 방송 플랫폼 라이브러리를 예시로 들면, 자바 17을 유지하면서 굉장히 안정적인 성능을 보여줬습니다.
전반적으로 논블로킹 구조로 되어있는데 대략 200개 이상의 채널과 연결해도 크게 이슈가 없더라구요.
자바 버전을 21로 강제하는게 썩 좋을진 모르겠습니다.(제 워크스페이스가 자바 버전에 민감합니다.. 물론 지극히 드문 케이스)

[getCurrentThread]

https://github.com/R2turnTrue/chzzk4j 다른 방송 플랫폼 라이브러리를 예시로 들면, 자바 17을 유지하면서 굉장히 안정적인 성능을 보여줬습니다. 전반적으로 논블로킹 구조로 되어있는데 대략 200개 이상의 채널과 연결해도 크게 이슈가 없더라구요. 자바 버전을 21로 강제하는게 썩 좋을진 모르겠습니다.(제 워크스페이스가 자바 버전에 민감합니다.. 물론 지극히 드문 케이스)

@sj-hub9796
의견 주셔서 감사합니다.

저도 업무상 JDK17을 써야하는 입장이다보니, 동일하게 버전을 올리는 것에 부정적인 입장이긴 합니다.
올려주신 링크의 라이브러리 코드 참고하여서 논블로킹 구조로 한번 재적용해보도록 하겠습니다. :)

[sj-hub9796]

@sj-hub9796 의견 주셔서 감사합니다.

저도 업무상 JDK17을 써야하는 입장이다보니, 동일하게 버전을 올리는 것에 부정적인 입장이긴 합니다. 올려주신 링크의 라이브러리 코드 참고하여서 논블로킹 구조로 한번 재적용해보도록 하겠습니다. :)

저도 시간날때 한번 PR 남겨보도록 하겠습니다. 혹시 TODO 태스크를 정리하실 예정이신가요?

[getCurrentThread]

저도 시간날때 한번 PR 남겨보도록 하겠습니다. 혹시 TODO 태스크를 정리하실 예정이신가요?

@sj-hub9796
PR 기여해주시면 정말 좋을 것 같습니다. 👍

현재 TODO 태스크는 별도로 정리되어 있지 않지만,
논블로킹 구조 적용을 위한 작업을 진행하면서 필요한 태스크들을 곧 정리할 예정입니다.
정리되는 대로 이슈에 업데이트하겠습니다.

혹시 특별히 작업하고 싶으신 부분이 있으시면 알려주시면 감사하겠습니다. 🥰

[sj-hub9796]

@sj-hub9796 PR 기여해주시면 정말 좋을 것 같습니다. 👍

현재 TODO 태스크는 별도로 정리되어 있지 않지만, 논블로킹 구조 적용을 위한 작업을 진행하면서 필요한 태스크들을 곧 정리할 예정입니다. 정리되는 대로 이슈에 업데이트하겠습니다.

혹시 특별히 작업하고 싶으신 부분이 있으시면 알려주시면 감사하겠습니다. 🥰

제 실력이 닿는선에서 최대한 기여를 하고싶은데 아직 어떤 작업을 해야할지, 무엇을 할 수 있는지 감이 안잡힌 상태네요.
어느정도 작업해야할것들이 확정되면 그때 살펴볼 예정입니다.

[sj-hub9796]

아, 추가로 현재 숲 공식 api 기능을 일부 구현한 바 있습니다.(로그인 및 토큰 인증) 추후 해당 기능을 병합해보는것도 좋겠네요. 물론 clientId, clientSecret을 필요로 합니다.

[getCurrentThread]

@sj-hub9796
안녕하세요. 오랜만에 이슈 업데이트를 드리게 되었네요.

우선 이슈 제보와 적극적인 논의, 그리고 직접 120채널 이상 테스트까지 해주신 부분 정말 감사합니다.
chzzk4j 라이브러리 사례도 공유해주신 덕분에 논블로킹 구조에 대한 방향을 잡는 데 큰 도움이 되었습니다.

---

솔직하게 말씀드리면, 당시 논의에서 JDK 17을 유지하면서 논블로킹 구조로 리팩토링하겠다고 말씀드렸었는데...
이후 Java 생태계 전반의 흐름이 꽤 빠르게 변하면서 방향을 전환하게 되었습니다.

• Oracle JDK 17 Premier Support가 2026년 9월에 종료 예정
• Spring Boot 3.5 (마지막 3.x) OSS 지원이 2026년 6월 종료
• Spring Boot 4.0이 2025년 11월에 출시되면서 JDK 21/25를 권장
• JDK 25 LTS가 2025년 9월에 출시되어 Premier Support가 2030년 9월까지

국내 생태계도 Spring Boot 4.x 의존성을 따라 JDK 21+ 전환이 자연스러운 흐름이 되고 있어서,
JDK 25 기반으로 Virtual Threads(JEP 444)와 Structured Concurrency를 적용하는 쪽으로 결정했습니다.

저도 당시에 업무상 JDK 17을 쓴다고 말씀드렸던 부분이 있어서...
방향이 달라진 점에 대해서는 양해 부탁드립니다. 🙏

---

이 이슈에서 논의되었던 성능 문제를 해결하기 위해 v0.2.0에서 아래와 같은 변경을 진행했습니다.

• Virtual Threads + Structured Concurrency 도입: 채널당 개별 플랫폼 스레드를 할당하던 기존 구조에서 벗어나, Virtual Threads 기반으로 전환하여 다수 채널 동시 연결 시에도 컨텍스트 스위칭 오버헤드를 최소화했습니다.
• 이벤트 드리븐 아키텍처: 93개 이상의 타입 세이프 이벤트를 Sealed Class 계층 구조와 Java Record로 정의하여 메시지 처리 파이프라인을 재설계했습니다.
• CompletableFuture 기반 비동기 처리: 블로킹 호출을 제거하고 비동기 처리 흐름을 적용했습니다.
• 자동 재연결 + 지수 백오프: WebSocket 연결 끊김 시 자동 재연결과 지수 백오프를 통해 안정성을 확보했습니다.
• SoopClient 통합 API: 인증, 방송 정보, 채널 정보, 채팅 관리를 하나의 클라이언트로 통합했습니다.

---

v0.2.0 변경사항으로 해당 성능 이슈가 해결되었다고 판단하여 이슈를 클로징합니다.
혹시 추가로 확인이 필요하시거나 새로운 문제가 발견되시면 언제든지 이슈 다시 열어주시면 감사하겠습니다.

다시 한번 관심과 피드백 감사합니다..!