inflearn logo
강의

강의
N
챌린지

챌린지
멘토링

멘토링
N
클립

클립
로드맵

로드맵
지식공유

BeakGwa님의 게시글

BeakGwa BeakGwa

@beakgwa

수강평 작성수
8
평균평점
5.0

게시글 8

질문&답변

api 요청 횟수와 시나리오 갯수에 대해 질문 있습니다.

결론부터, 해당하는 조건에 명확하게 몇번의 api가 실행되는지는 단정할 수 없습니다. 단, 다음과 같이 어느정도 예상은 해볼 수 있습니다. 1초당 3명의 가상 유저를 생성하게 되고, 30초 동안 총 90명의 가상 유저를 생성하게 됩니다. 각 시나리오에 (현재 2개) 가상 유저를 배정해야 하는데, Artilleryt 에서는 비균등하게 배치가 되고 있습니다. 각 시나리오가, 42유저/48유저 (시나리오1/시나리오2) 만큼 배치되었다고 가정 해보면 다음과 같습니다. 1번 시나리오 : 42 * 3 (유저 x api 갯수) = 총 126개의 api 호출 2번 시나리오 : 48 * 1 = 48개의 api 호출 이런식으로 가정해서 확인해볼 수 있습니다. config: target: 'http://localhost:8080' phases: - duration: 30 arrivalRate: 3 name: Warm up scenarios: - name: "login and use some functions" flow: - post: url: "/login" - get: url: "/some-function-one" - get: url: "/some-function-two" - name: "just login" flow: - post: url: "/hello" weight 같은 가중치를 줘서 최대한 균등하게 배정하는 방법또한 소개되는것으로 확인되는데, 정확하게 동작하는지는 저도 테스트는 안해보았습니다. https://www.artillery.io/docs/reference/test-script#scenario-weights

좋아요수
1
댓글수
3
조회수
322

질문&답변

Spring REST Docs 관련 질문 사항

비슷한 생각을 가진 여러 수강생에 남겨주신 질문 확인하였습니다! 감사합니다~

좋아요수
0
댓글수
3
조회수
336

질문&답변

세션 타임아웃과 refresh token

저도 동일하게 궁금해서 정리한 개인적인 의견을 한번 공유드립니다. (개인 의견 가득) 1. 탈취되었을때를 가정하여, accessToken 이 탈취될 경우, 지속적인 유효기간 연장 작업으로, 탈취자는 무한정 접근 권한 을 가질 수 있습니다. 이는 보안이슈 로 큰 문제가 될 것으로 생각됩니다. - 본 강의에서 나오는 session 타임아웃 연장 또한 같은 문제 있을 것으로 생각. 현업에서는 동일한 방식으로 연장 하는지, 새로운 session을 생성하는지는 저도 의문입니다. 2. 1번의 보안이슈 를 해결하기 위해서, 로그인시 발급한, refresh token 으로 새로운 access token 을 발급하여 client에게 전달합니다. 이때 이전에 발급한 access token은 사용이 불가능 합니다. - 짧은 expired time을 설정하여, 이미 발급된 access token이 탈취당한 상황을 우려, refresh token을 사용하여 새로운 인증token을 발급하여 보안이슈 회피 - 기존 사용하던 AccessToken은 ExpiredTime이 다되서 당연히 사용 불가. (탈취된거? 사용 안돼!) 결론) 결국 refresh token을 적용하게 된 이유는, 사용자 경험성 증가를 위해, 긴 로그인 시간을 지원하게 하고, 보안 이슈를 해결하기 위해 적용되었다고 생각합니다. 같이 토론해주세요!

좋아요수
0
댓글수
1
조회수
365

질문&답변

unlock()에 synchronized를 걸면 왜 무한루프를 도는지가 이해가 안됩니다..ㅠㅠ

현재 SpinLockBad class의 lock(), unlock() 메서드는 해당 클래스의 private volatile boolean lock 을 true 혹은 false로 변경시키면서 lock을 제어하고 있습니다. 하지만, synchronized 를 사용하게 되면, 내부 락 을 따로 사용하게 되는거죠. 여기서 synchronized 를 통해 사용되는 lock 은 lock(), unlock() 메서드에 상관없이 메서드가 시작할때 내부 락 을 획득 시도, 끝날때 내부 락 을 반납 하게 됩니다. 결국, 해당 SpinLockBad 클래스는 volatile boolean 타입 lock 하나 synchronized 키워드를 통해 제어하는 내부 lock 하나 이렇게 두가지 lock을 사용하게 되서 문제가 발생하게 된거죠.

좋아요수
1
댓글수
2
조회수
282

질문&답변

unlock()에 synchronized를 걸면 왜 무한루프를 도는지가 이해가 안됩니다..ㅠㅠ

main 코드가 있어야 확인이 가능할 것 같은데, 현재 확인된 코드로는 lock 전략이 두가지 설정되어있는 것 같습니다. volatile lock , synchronized lock synchronized 키워드를 사용해서 락 전략을 실현하면, 해당 클래스의 내부 lock 을 사용하게됩니다. 이 lock 은 synchronized 키워드가 붙은 메서드 or 임계영역 이 완료될떄까지 lock 을 반납하지 않습니다. volatile lock 으로 lock()/unlock() 메서드를 사용하여 락을 제어한다고 해도, synchronzed 의 내부 락은 반납하지 않기때문에, 질문에 있는 무한 대기 상태가 걸리는 것으로 예상됩니다. 공식 답변이 아니라서 틀릴수도 있는점 양해 부탁드립니다.

좋아요수
1
댓글수
2
조회수
282

질문&답변

List인터페이스를 sout 할때 질문입니다.

저도 질문글 보니 궁금해서 디버깅하면서 뒤져봤네요. 결론적으로는 AbstractCollection 클래스의 의 toString 메서드를 사용하는게 맞습니다. List list = new LinkedList (); list.add("data1"); System.out.println("list = " + list); list를 문자열로 반환하기 위해서 String class의 valueOf 실행. 여기서 Object의 toString 메서드 실행. toString 실행 시, 해당 Object의 오버라이딩 된 toString, AbstractCollection.toString 실행 이런 순서로 이뤄지는걸로 확인하였습니다.

좋아요수
0
댓글수
1
조회수
283