
특정 시기에 몰리는 부하테스트도 인정,
더미계정을 생성하여 부하테스트를 할때, 시나리오어떻게 짜는게 좋은지,
chatBoxId.animate({ scrollTop: $(document).height() }, "slow");
=> 이코드는 실시간적인 즉각적인 이벤트를 보여주는 역할보다 타이머를 두고
천천히 스크롤을 올려주는 역할이 어울릴것 같다.
------------------------ Artillery Keywords--------------------------------------
# Config section
redis - redis에 저장되는 값이나 저장된 값을 불러올수 있는지? 어떻게 불러오는지 ?
defaults - 시나리오의 기본값을 지정, 어떤 것을 기본 값으로 지정하면 될 지 ?
plugins - githubaction, redis, kubernetis,
ensure - 에러나 지연시간에 대한 성공조건 세팅, 불필요한 리소스 낭비 줄이기 ? 체크 ?
processor - 커스텀 js 코드를 load, 활용방안 모색하면 좋을듯
phases
- arrivalCount : duration / arrivalCount 식으로, 가상유저 생성, duration이 60이고 arricalCount가 20이면,
약 3초마다 1명씩 생성
config:
target: "https://staging.example.com"
phases:
- duration: 60
arrivalCount: 20
- maxVusers : duration에 설정값 동안 arricalRate의 설정 값만 큼 가상유저 생성하는데,
주어진 시간내에서 가상유저가 생성되는 최대치를 설정.
config:
target: "https://staging.example.com"
phases:
- duration: 300
arrivalRate: 10
maxVusers: 50
config.enviroments를 구성하면
# Secnarios Section
caption - 응답으로 받은 데이터를 변수로 지정하여 뒤에 보내는 요청에 사용할 수 있다.
소켓에서 적용방안 모색필요. redis로 보내는 값을 가져올수 있다면 좋을듯
match - caption과 같이 활용하면 좋을듯
weight - 시나리오 가중치 설정, 이 값이 높으면 해당 시나리오 발생률이 높아진다.
------------------------- 결론 ?---------------------
테스트를 진행할수록 요청을 처리하는 속도가 점점 느려진다는 것은 서버가 부하 테스트를
하는 정도의 요청을 감당하지 못한다는 뜻이므로 서버의 사양을 업그레이드 하거나,
서버를 늘리거나 코드를 효율적으로 개선해야 한다.
노드가 싱클코어만 사용하고 있기에 클러스터링 같으 ㄴ기법을 통해 서버를 여러개 실행하는 것을
우선적으로 시도해볼만 함.
일반적으로는 요청 - 응답시 데이터베이스에 접근할 때 가장 많은 시간이 소요된다.
=> 자주 요청되는 데이터에 대해서 캐싱하면 좋다
서버의 성능과 네트워크 상황에 따라 arrivalRate를 줄이거나 늘려 서버가 어느정도 까지 버틸 수
있는지 테스트 해보는 것이 좋고 여러 번 같은 설정값으로 테스트 하여 평균치를 내보는 것이 좋다.
----------------------- 그래프 설명 -------------------------------
세로는 Latency(지연시간), 가로는 시간을 나타낸다.
max - 가장 오래걸린 요청 -> 응답 시간
p95 - 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95%까지 ( 거의 대부분의 트래픽이 포함 )
p50 - 전체 HTTP 트랜잭션중 가장 빠른 것부터 50%까지 ( 절반의 트래픽이 포함)
min - 가장 빠르게 온 요청 -> 응답 시간
-----------------------알고 가자--------------------------------------
info
The duration of an arrival phase determines only how long virtual users will be generated for. It is not the same as the duration of a test run. How long a given test will run for depends on several factors, such as complexity and length of user scenarios, server response time, and network latency.
정보
도착 단계의 기간은 가상 사용자가 생성되는 기간만 결정합니다. 테스트 실행 기간과 동일 하지 않습니다 . 주어진 테스트가 실행되는 기간은 사용자 시나리오의 복잡성과 길이, 서버 응답 시간, 네트워크 대기 시간과 같은 여러 요인에 따라 달라집니다.
'항해99 > TIL' 카테고리의 다른 글
항해99 58일차 TIL (0) | 2022.11.15 |
---|---|
항해99 57일차 TIL (0) | 2022.11.15 |
항해99 52일차 TIL (0) | 2022.11.10 |
항해99 51일차 TIL (0) | 2022.11.09 |
항해99 49일차 TIL (0) | 2022.11.07 |

특정 시기에 몰리는 부하테스트도 인정,
더미계정을 생성하여 부하테스트를 할때, 시나리오어떻게 짜는게 좋은지,
chatBoxId.animate({ scrollTop: $(document).height() }, "slow");
=> 이코드는 실시간적인 즉각적인 이벤트를 보여주는 역할보다 타이머를 두고
천천히 스크롤을 올려주는 역할이 어울릴것 같다.
------------------------ Artillery Keywords--------------------------------------
# Config section
redis - redis에 저장되는 값이나 저장된 값을 불러올수 있는지? 어떻게 불러오는지 ?
defaults - 시나리오의 기본값을 지정, 어떤 것을 기본 값으로 지정하면 될 지 ?
plugins - githubaction, redis, kubernetis,
ensure - 에러나 지연시간에 대한 성공조건 세팅, 불필요한 리소스 낭비 줄이기 ? 체크 ?
processor - 커스텀 js 코드를 load, 활용방안 모색하면 좋을듯
phases
- arrivalCount : duration / arrivalCount 식으로, 가상유저 생성, duration이 60이고 arricalCount가 20이면,
약 3초마다 1명씩 생성
config:
target: "https://staging.example.com"
phases:
- duration: 60
arrivalCount: 20
- maxVusers : duration에 설정값 동안 arricalRate의 설정 값만 큼 가상유저 생성하는데,
주어진 시간내에서 가상유저가 생성되는 최대치를 설정.
config:
target: "https://staging.example.com"
phases:
- duration: 300
arrivalRate: 10
maxVusers: 50
config.enviroments를 구성하면
# Secnarios Section
caption - 응답으로 받은 데이터를 변수로 지정하여 뒤에 보내는 요청에 사용할 수 있다.
소켓에서 적용방안 모색필요. redis로 보내는 값을 가져올수 있다면 좋을듯
match - caption과 같이 활용하면 좋을듯
weight - 시나리오 가중치 설정, 이 값이 높으면 해당 시나리오 발생률이 높아진다.
------------------------- 결론 ?---------------------
테스트를 진행할수록 요청을 처리하는 속도가 점점 느려진다는 것은 서버가 부하 테스트를
하는 정도의 요청을 감당하지 못한다는 뜻이므로 서버의 사양을 업그레이드 하거나,
서버를 늘리거나 코드를 효율적으로 개선해야 한다.
노드가 싱클코어만 사용하고 있기에 클러스터링 같으 ㄴ기법을 통해 서버를 여러개 실행하는 것을
우선적으로 시도해볼만 함.
일반적으로는 요청 - 응답시 데이터베이스에 접근할 때 가장 많은 시간이 소요된다.
=> 자주 요청되는 데이터에 대해서 캐싱하면 좋다
서버의 성능과 네트워크 상황에 따라 arrivalRate를 줄이거나 늘려 서버가 어느정도 까지 버틸 수
있는지 테스트 해보는 것이 좋고 여러 번 같은 설정값으로 테스트 하여 평균치를 내보는 것이 좋다.
----------------------- 그래프 설명 -------------------------------
세로는 Latency(지연시간), 가로는 시간을 나타낸다.
max - 가장 오래걸린 요청 -> 응답 시간
p95 - 전체 HTTP 트랜잭션 중 가장 빠른 것부터 95%까지 ( 거의 대부분의 트래픽이 포함 )
p50 - 전체 HTTP 트랜잭션중 가장 빠른 것부터 50%까지 ( 절반의 트래픽이 포함)
min - 가장 빠르게 온 요청 -> 응답 시간
-----------------------알고 가자--------------------------------------
info
The duration of an arrival phase determines only how long virtual users will be generated for. It is not the same as the duration of a test run. How long a given test will run for depends on several factors, such as complexity and length of user scenarios, server response time, and network latency.
정보
도착 단계의 기간은 가상 사용자가 생성되는 기간만 결정합니다. 테스트 실행 기간과 동일 하지 않습니다 . 주어진 테스트가 실행되는 기간은 사용자 시나리오의 복잡성과 길이, 서버 응답 시간, 네트워크 대기 시간과 같은 여러 요인에 따라 달라집니다.
'항해99 > TIL' 카테고리의 다른 글
항해99 58일차 TIL (0) | 2022.11.15 |
---|---|
항해99 57일차 TIL (0) | 2022.11.15 |
항해99 52일차 TIL (0) | 2022.11.10 |
항해99 51일차 TIL (0) | 2022.11.09 |
항해99 49일차 TIL (0) | 2022.11.07 |