[NHN FORWARD 2020] 내가 만든 WebFlux가 느렸던 이유

Рет қаралды 16,835

NHN Cloud

Күн бұрын

Пікірлер: 73

@jasonseo7424 Жыл бұрын

2년전 영상에서 정답을 찾았습니다 😢

@이하생 2 күн бұрын

요즘 Webflux 사용하는데 흥미롭게 잘 보았습니다.

@vjdi2733 Жыл бұрын

현재 API 게이트웨이를 구현하기 위해 사용중인데 좋은 내용이네요 감사합니다

@정유경-d5q 4 жыл бұрын

천천히 차근차근 설명해 주시니까 너무 듣기 편안하고 좋네요. 또 좋은 발표 부탁드립니다. :)

@NHNCloud 4 жыл бұрын

좋은 의견에 감사드리고자 기프티콘을 12월 23일까지 보내드릴 예정입니다 :-) 아래 정보를 forward@nhn.com 메일로 보내 주세요. - KZbin 댓글 ID - NHN FORWARD 사이트에 등록하신 '이름/메일 주소' * 아직 사이트에 등록하지 못한 분은 forward.nhn.com 사이트 오른쪽 상단의 [로그인]을 눌러 등록하실 수 있습니다.

@dongmyo 4 жыл бұрын

좋은 내용이네요. 관심있던 주제였는데 덕분에 또 하나 배워갑니다.

@NHNCloud 4 жыл бұрын

좋은 의견에 감사드리고자 기프티콘을 보내드릴 예정입니다 :-) 아래 정보를 forward@nhn.com 메일로 보내 주세요. - KZbin 댓글 ID - NHN FORWARD 사이트에 등록하신 '이름/메일 주소' * 아직 사이트에 등록하지 못한 분은 forward.nhn.com 사이트 오른쪽 상단의 [로그인]을 눌러 등록하실 수 있습니다.

@redutan 4 жыл бұрын

좋은 발표 잘 보고 갑니다.

@NHNCloud 4 жыл бұрын

@IR0NMAN Жыл бұрын

감사합니다. 👍

@Person_00001 Жыл бұрын

좋은 영상 감사드립니다 고민을 덜어주셔서 얻어가는 이점이 많네요 정말 감사합니다😊❤

@NHNCloud 4 жыл бұрын

▶▶ 의견이나 질문을 댓글로 남겨 주시면 발표자가 확인하는 대로 답변드리겠습니다.

@꿀벌-w1b 3 жыл бұрын

좋은 발표 감사합니다! 많이 배우고 갑니다

@김삿갓-z4q 3 жыл бұрын

너무 좋은 내용 공유 정말 감사드립니다 ! 잔디밭 수북한것과 6,000에 가까운 TPS를 보니 제가 더 흥분되네요ㅋㅋㅋ

@NHNCloud 2 жыл бұрын

좋은 말씀 감사합니다!

@skeonlee8500 4 жыл бұрын

내용이 깔끔하게 정리되어있어 좋습니다.

@Jason-qs2pp 4 жыл бұрын

와 요새 찾아보는 중인데 내용감사합니다. 경험에서 나오는 이런게 제일 중요합니다. 너무 좋은내용 감사합니다. !!

@icj5874 4 жыл бұрын

성능 수치와 해결 과정이 자세히 설명되어 매우 유용하였습니다. 감사합니다 👍

@money_talks666 3 жыл бұрын

좋은 내용, 좋은 발표 감사합니다..^^

@mooheelee1004 4 жыл бұрын

발표 잘 보았습니다. 내용이 아주 좋네요~

@NHNCloud 4 жыл бұрын

@AstroKorea 8 ай бұрын

매우 유용한 내용이네요. 감사합니다.

@김준현-g2q 4 жыл бұрын

궁금했던 주제였는데 공유해주셔서 감사합니다 :)

@NHNCloud 4 жыл бұрын

좋은 의견에 감사드리고자 12월 23일까지 기프티콘을 보내드릴 예정입니다. * 경품 수령 양식 작성: t0a.st/AFgQ * 아직 사이트에 등록하지 못한 분은 forward.nhn.com 사이트 오른쪽 상단의 [로그인]을 눌러 등록하실 수 있습니다.

@dongbin629 2 жыл бұрын

감사합니다. 유익한 내용 덕분에 도움이 많이 되었습니다.

@전성한-t2k 3 жыл бұрын

좋은 내용 감사드립니다.

@하성호-h4b 2 жыл бұрын

감사합니다.

@seonwookim5391 3 жыл бұрын

설명이 정말 깔끔하고 잘하시네요. 많이 배우고 갑니다 감사합니다

@jeongwoopark1031 3 жыл бұрын

정말 좋은 내용이네요

@gunamjung 4 жыл бұрын

차근차근 잘 설명해주셔서 좋았어요!

@NHNCloud 4 жыл бұрын

@최현범-n3c 3 жыл бұрын

너무 유익한 강의, 잘 들었습니다.

@두리두두-g4b 3 жыл бұрын

감사합니다 좋은내용이네요~

@박수현-d4j 3 жыл бұрын

잘봤습니다:) 웹플럭스 사용중인데 실제로 도움을 받았습니다. 감사합니다:)

@NHNCloud 2 жыл бұрын

도움이 되셨다니 다행입니다.

@sehaeng 4 жыл бұрын

최근 관련된 내용을 공부하고있는데 많은 도움이 되었습니다.

@NHNCloud 4 жыл бұрын

좋은 의견에 감사드리고자 12월 25일까지 기프티콘을 보내드릴 예정입니다. * 경품을 받으시려면 forward.nhn.com 사이트에 미리 등록돼 있어야 합니다. * 경품 수령 양식 작성: t0a.st/AFgQ

@xacdo 4 жыл бұрын

잘 보았습니다

@NHNCloud 4 жыл бұрын

@by-gv6mq 4 жыл бұрын

좋은 내용 잘 봤습니다~

@NHNCloud 4 жыл бұрын

의견에 감사드리고자 기프티콘을 보내드릴 예정입니다 :-) 아래 정보를 forward@nhn.com 메일로 보내 주세요. - KZbin 댓글 ID - NHN FORWARD 사이트에 등록하신 '이름/메일 주소' * 아직 사이트에 등록하지 못한 분은 forward.nhn.com 사이트 오른쪽 상단의 [로그인]을 눌러 등록하실 수 있습니다.

@Negan8269 4 жыл бұрын

잘봤습니다~ 이해하기 쉽게 잘 설명해주셔서 감사합니다~

@NHNCloud 4 жыл бұрын

@nick6267 4 жыл бұрын

저희 회사에서도 현재 일부분이지만 indexer 쪽을 webflux로 진행하고 있습니다^^ 참고 되서 좋네요

@NHNCloud 4 жыл бұрын

@juro804 Жыл бұрын

대규모 응답에 대한 서비스를 개인적으로 만들어보고 싶은 생각이 있긴한데 장난이 아니었네요. BlockHound처럼 map과 같은 동기 메소드 자체를 못쓰게 하기 위해 자바 객체를 일부러 별도의 비동기 전용 객체로 한번 더 감싸서 map을 못쓰게 하는 방법이나 그런 라이브러리가 개발된게 있지 않을까 하고 고민하게 되네요.

@modu4755 Жыл бұрын

지렸다 .

@alhightam 4 жыл бұрын

relation db를 사용하는 경우 r2dbc를 검토할수 밖에 없는데 상용화에 사용해보신 경험이 있으신가요? 커뮤니티에서 관련된 이야기를 보면 아직 부족하다 위험하다등 이야기가 많습니다.

@발표자-s8m 4 жыл бұрын

Production 에서 아직 배포해본적이 없습니다. 현상황에서 개인적으로 RDB 로 r2dbc 를 이용하여 개발하고 싶은 생각이 없습니다. Transaction 을 사용하기 위해서 RDB를 사용하는데, 아직 충분한 신뢰와 레퍼런스가 없어서 사용하고 싶지 않습니다. 또한 지금 하고 있는 일들이 RDB를 이용해서 데이터의 정합성을 보장받아야 하는 일입니다. 그래서 목적과 신뢰 측면에서 사용하지 않고 있습니다.

@alhightam 4 жыл бұрын

@@발표자-s8m 그렇다면은 reactor 라이브러리 내에서 jdbc가 블럭킹이라서 사용하는것은 보기 안좋지만 pool격리를 해서 유지하는게 만족도가 높을수 있겠군요.

@NHNCloud 4 жыл бұрын

@jinKorlover 4 жыл бұрын

안녕하세요, 좋은 발표 감사합니다. 질문이 있습니다. 21:40 분에서, 그래프가 약간 떠 있는 걸 본다면 코드에 문제가 없는지 의심해봐야 한다고 하셨는데요. 코드에서 의존하는 외부 client가 늦게 응답을 준다면, blocking 코드 유무와 관련 없이, 그래프가 떠 있을 수 밖에 없지 않나요? 제가 이해한 바로는, 어떤 요청을 non blocking으로 처리한다는 건, 그 요청 처리 시간을 빠르게 하는 게 아니고요. 그 요청이 외부 client를 기다리는 동안 노는 cpu를 다른 요청이 쓸 수 있게끔하는 것으로 이해했는데요. 특정 요청 a에게 외부 client가 늦게 응답을 준다면, 그 요청의 처리 시간이 늦어지는 건 webflux, web mvc 둘 다 똑같은 것 아닌가?라는 생각이 들어 질문드려요. 요즘 webflux, non blocking 관련 개념을 공부하는 데 헷갈리는 게 많아서, 답변 주시면 이해에 큰 도움 될 것 같습니다. 감사합니다!

@NHNCloud 4 жыл бұрын

좋은 의견에 감사드리고자 12월 23일까지 기프티콘을 보내드릴 예정입니다. 경품을 받으시려면 양식(t0a.st/AFgQ) 을 작성해 제출해 주시기 바랍니다. * 아직 사이트에 등록하지 못한 분은 forward.nhn.com 사이트 오른쪽 상단의 [로그인]을 눌러 등록하실 수 있습니다.

@byungboor 4 жыл бұрын

넵 맞습니다. 코드에서 외부 클라이언트가 늦게 응답을 준다면 그 시간만큼 떠 있을 수 밖에 없습니다. 제가 설명이 약간 부족했네요. 보충의견 드립니다. REDIS는 응답 시간이 1ms 정도 인데, 저렇게 떠있는 구간이 일정하게 보인다면 코드에 문제가 있는지 없는지 의심해봐야 한다 라고 자세히 말씀드렸어야 했네요. 의견 감사합니다.

@jinKorlover 4 жыл бұрын

@@byungboor 님, 답변 감사합니다! web flux 공부에 큰 도움이 되었어요.

@kindcode 3 жыл бұрын

감사합니다 map flatmap 사실 모르고 썻는데…. 덕분에 서버 코드 수정해서 좀더 성능을 좋게해야겠네요!

@hanmomhanda 4 жыл бұрын

유익한 내용 간명하게 잘 정리해주셔서 감사합니다! 웹플럭스(리액터+네티)에서 스레드 4개가 사용 되면 그 중 한 개는 이벤트루프만, 그러니까 요청 큐에서 요청을 꺼내가는 일만 전담하고 나머지 3개가 실제 요청을 처리하는 식으로 역할 분담이 되는 건가요? 아니면 4개가 모두 요청 큐를 바라보고 하나씩 꺼내서 처리하는 동일한 일을 그냥 나눠서 처리하는 건가요?

@haekyucho4171 4 жыл бұрын

single thread가 아니라 small threads로 동작합니다.(cpu 코어수) 스레드 4개가 이벤트 루프로 동작하고 어쩔수 없는 blocking코드일 경우 publishOn같은 메소드를 사용하여 쓰레드 풀에 격리시키는 방향으로 개발하였습니다.

@발표자-s8m 4 жыл бұрын

Java 의 ServiceExecutor 와 개념적으로 같이 동작합니다. free 한 4개의 스레드들이 있다면 모두 요청 큐를 보고 작업을 처리합니다.

@hanmomhanda 4 жыл бұрын

@@발표자-s8m 답변 고맙습니다. 좋은 정보 공유 다시 한 번 감사드립니다~~

@hanmomhanda 4 жыл бұрын

@@haekyucho4171 답변 감사합니다~~

@NHNCloud 4 жыл бұрын

질문에 감사드리고자 기프티콘을 보내드릴 예정입니다 :-) 아래 정보를 forward@nhn.com 메일로 보내 주세요. - KZbin 댓글 ID - NHN FORWARD 사이트에 등록하신 '이름/메일 주소' * 아직 사이트에 등록하지 못한 분은 forward.nhn.com 사이트 오른쪽 상단의 [로그인]을 눌러 등록하실 수 있습니다.

@gunlee00 4 жыл бұрын

놓치기 쉬운 부분, 잘 모르고 사용하면 문제가 될 부분들을 너무 잘 풀어서 설명해 주셔서 정말 많은 도움이 많이 되었습니다. 감사합니다~ 시간상 성능 시험에 관련된 상황을 자세히 설명해 주시지는 못한 듯 한데 부하가 다 들어간 상황(램프업 끝나고 스캐터 차트가 수평인 상황, 더이상 TPS가 늘어나지 않았을때)에서 각각(mvc, webflux)의 자원 상황과 mvc이 max-thread 설정도 궁금한데 추가적인 정보를 알 수 있을까요? 그리고 1000 vuser를 사용했다고 하셨는데 think time이 있었던 것인지도 궁금하네요~ 질문만 잔뜩 드렸습니다~ :) 좋은 내용 다시 한번 감사드립니다.

@byungboor 4 жыл бұрын

성능 테스트 때, cpu usage 를 캡쳐한것이 있었으면 좋았을텐데.. 기억에 의존할 수 밖에 없어서 안타깝네요. 기억으로는 MVC 는 거의 100% 에 가까운 cpu usage 를 보여줬고, webflux 는 약 80% 정도 선이였던것 같습니다. mvc, webflux 모두기본 설정값으로 했습니다. 그래서 max = 200 입니다. think time 은 없었습니다. api 자체가 단순한 내용이라 시나리오 구성도 하지 않고 단순 부하 테스트가 목적이었습니다.

@NHNCloud 4 жыл бұрын