대머리개발자

조금이라도... 나아진 퍼포먼스를 보여주기 위한 비동기 선택 본문

개발이야기/성능

조금이라도... 나아진 퍼포먼스를 보여주기 위한 비동기 선택

대머리개발자 2024. 9. 4. 10:41
728x90

매번 할 때마다 찾아보는..녀석이라...정리 좀 하자.

이해를 정확하게 못했기 때문에 매번 찾아본다고 생각한다. ㅠㅠ 또또 정리하자..

//  I/O 작업이나 블로킹 작업을 처리하기 위한 스케줄러입니다
Schedulers.boundedElastic()
// 별도 외부 API 호출할때나 혹은 대용량 엑셀 혹은 파일처리 할 때 기타.. 등등 좋겠다.


// 짧은 시간 내에 끝나는 CPU 바운드 작업을 처리하기 위한 스케줄러입니다.
Schedulers.parallel()
// 한방 쿼리를 좋아하지만..어째거나 여러개의 쿼리를 쨉쨉이 날리 때 기닽.. 등등 좋겠다.


// 두 친구의 차이는 반환값이 있고 없고
Mono.fromRunnable() vs Mono.fromCallable()

 

 

비동기로 처리해도 문제 없는 것들은 비동기로 처리하는 것이 좋다. .. 두 말 하면 아이유!!

 

예를들어 보자.

 

예제1)

화면에  게시판 목록을 표현하기 위해서는 1.목록과 2.목록에 대한 카운트가 필요하다.

 

목록은 당연한 거쥬. 카운트는 페이징 처리릉 위해서 필요하다.

 

목록 리스트 로직이 5초, 카운트 로직이 2초 걸린다고 하면 총 7초가 걸린다.

 

근데 비동기로 처리하면 5초가 걸리는 거다.

Mono.zip을 이용해서병렬(동시)로 처리... 가장 오래 걸리는 친구가 "기준"으로 처리 된다고 생각하면 된다.

## 비동기 처리
Mono.zip(
ServiceUtil.getUserService().countDynamicUserList(request.getFilter(), request.getUserType()),
ServiceUtil.getUserService().searchDynamicUserList(request.getFilter(), request.getUserType()).collectList()
)
.map( it -> ..)
...

 

예제2)

 

사용자 탈퇴를 하면서 1.기존 작성되었던 게시판 및 댓글을 지우고 2. 탈퇴를 진행하는 것이다.

 

별도의 외부 API를 호출하고 결과값은 의미 없기 때문에.. fromRunnable()로 진행!

 

역시나 순차적으로 진행하면 응답값은 똥망이 되겠지..

But HttpRequest를 논블록킹 처리하면 비슷한 효과를 낼 수 있겠다.

(왜? 드디어 민머리가 될 수 있는 기회를 잡으셧다!!..고민 해 봐라 ㅋㅋ)

 

public void delete(UserGrpc.User request, StreamObserver<UserGrpc.User> responseObserver) {
    String userUID = ContextUtil.getContext().getUid();
    // http://community-service
    Mono.fromRunnable(() -> {
         HttpRequest.delete( Constants.COMMUNITY_URI + "/boards/-777")
                    .authorization("Bearer " + ContextUtil.getContext().getUserKey())
                    .ok();

        HttpRequest.delete(Constants.COMMUNITY_URI + "/comments/-777")
        .authorization("Bearer " + ContextUtil.getContext().getUserKey())
        .ok();
     }).subscribeOn(Schedulers.boundedElastic()).subscribe();


    // 한방에 같이 업데이트 하면 좋을 텐데... 시댕..
    // 탈퇴 상태 먼저 update 진행
    // 탈퇴 사유!
    ServiceUtil.getUserService().update(
                                        UserGrpc.User.newBuilder()
                                        .setUid(userUID)
                                        .setFilter(oauth.common.CommonGrpc.Filter.newBuilder()
                                                .setBy(Constants.STATE).setValue(Constants.STATE_DELETE).build())
                                        .build())
            .concatWith(
                       ..
            )
            .map(it -> it.toBuilder().build())
    .subscribe(responseObserver::onNext, responseObserver::onError, responseObserver::onCompleted);
}

 

 

기존에 고민했던것을 다시 곱씹어 보니깐 이제는 조금은 이해 되었네 ㅋㅋ

https://hcnmy.tistory.com/203

 

비동기와 논블로킹, 리액티브

비동기와 논블로킹은 나는 같은 녀석이라고 본다.둘의 목표가 동일하기 때문이다.병렬처리하기 위함이다. 딱 끝!!! 그리고 모든 블로그가 같은 그림으로 동일한 설명을 하고 있다.되지도 않는

hcnmy.tistory.com

 

728x90

'개발이야기 > 성능' 카테고리의 다른 글

i5-13600K vs mac-m1 vs 네이버 VM  (0) 2024.01.03
이벤트 서버의 성능 테스트 시작(4)  (1) 2023.11.25
이벤트 서버의 성능 테스트 시작(3)  (1) 2023.11.23
webFlux VS webMVC(2)  (0) 2023.03.02
webFlux VS webMVC(1)  (0) 2023.02.09