nGrinder (JMeter)
When testing concurrency in n grinder, create 1000 users with a for statement before In the test part, the user should be taken out and used. Why do you need to have multiple agents when you upload Engrinder to the server? Because if there are only two agents, they run in limited threads. In conclusion, there is a downside of waiting time. To make more accurate tests, create multiple threads and run multiple threads in each. The test is conducted in a way that is used simultaneously.
Optimistic Lock vs Pessimistic Lock
I don't use locks well at work.
If you use locks, you block the transaction, so it becomes a bottleneck.
comes into being
We tried to solve the concurrency issue with pessimism, but @transactional and
The @lock level is set to the waiting number, so the lock cannot be passed when inserting.
A deadlock occurred.
This failed and we do not use the pessimistic lock itself because it has poor performance.
I found out that it was not, and I decided to deal with it with optimism.
We create a separate table to hold the waiting number, and
Optimistic locking solved the concurrency issue.
However, this is also a load test when 1000 users enter at once.
It was said that concurrency issues could be confirmed,
It was said that concurrency issues can be controlled using redis, sqs, and queues.
The structure responds in redis and stores in sqs and queue in turn
The response value is shown to the customer, but it is not yet processed in the back
It is a sequential processing method.
Also, in a situation where you need to make a payment rather than a queue,
Since it is not possible to make two payments at the same time, in this case, use the sql update statement
It is said to prevent concurrency. In the case of payment, absolutely twice
Because it is not possible, update is set to use the transaction only once unconditionally.
There is a way to defend against concurrency issues using this setting.
scheduler vs batch with jenkins
Scheduler processing is performed when the server is down when the service and server are connected.
The scheduler also has an issue that does not work. To prevent this,
Create another project inside the spring project and deploy in it
If you create and run Spring, they will be executed simultaneously. also
When the execution is completed, the jar file is divided and comes out.
In the existing project, update the jar required for deployment,
The batch jar files necessary for Jenkins are updated only at the appropriate time.
After that, it will not automatically update.
korean ver
nGrinder (JMeter)
n그라인더에서 동시성 테스트시 before에 유저를 for문으로 1000명만들고
테스트 부분에서 해당 유저를 꺼내 사용하는 방식으로 진행하여야한다.
엔그라인더는 서버에 올렸을때 여러개의 에이전트를 둬야 하는 이유는
하나의 에이전트만 두개되면 제한된 쓰레드에서 실행이 되기 때문에
결론적으로는 대기시간이 생기게 된다는 단점이 있다.
더 정확한 테스트를 하기 위해 여러 쓰레드를 만들고 각각의 여러 쓰레드를
동시에 사용하는 방법으로 테스트를 진행한다.
test는 가상의 쓰레드를 만드는 방식인데 쓰레드는 제한적이므로, 여러 쓰레드에도 한계가 존재한다.
--
Optimistic Lock vs Pessimistic Lock
현업에서는 락을 잘 쓰지 않는다.
락을 사용하게 되면 트랜잭션을 막아버리므로, 그렇게 되면 병목 현상이
생기게된다.
우리는 비관적락으로 동시성 이슈를 해결하려고 하였으나, @트랜잭셔널과
@lock레벨을 waiting number에 둘다 걸어버려 insert시 락을 통과하지못해
데드락이 발생하게 되었다.
이것은 실패하였고 우리는 비관적락 자체가 성능이 좋지않아 사용하지
않는다는것을 알게되고 낙관적 낙으로 대처를 하기로 하였고
우리는 waiting number를 가질 테이블을 따로 만들어, 해당 테이블을
낙관적 락을걸어 동시성 이슈를 해결 하였다.
하지만 이것 또한 부하 테스트로 1000명의 유저가 한번에 진입시
동시성 이슈가 생기는 것이 확인 될수 있다고 하였고,
redis와 sqs, queue를 사용하여 동시성 이슈를 제어 할 수 있다고 하였다.
구조는 redis에서 응답을하고 sqs와 queue에 저장을 차례로 하고
고객에겐 응답값을 보여주지만 뒤에서는 아직 처리되지 않는 상태가 되고
순차적으로 처리하는 방식이다.
또한 줄서기 방식이 아닌 payment를 만들어야하는 상황에서는
동시에 2번결제가 되면 안되므로, 이럴땐 sql의 update문을 사용해
동시성을 방지 한다고 한다. payment같은 경우는 절대적으로 두번이 되면
안되기때문에 update는 트랜잭션을 무조건1번만 사용하게 하는 설정이
있는데 해당 설정을 사용하여 동시성 이슈를 방어하는 것이다.
--
scheduler vs batch with jenkins
스케줄러 처리는 서비스와 서버가 연결이 되면 서버가 다운 되었을 때
스케줄러 또한 작동이 안되는 이슈가 발생한데 이것을 방지하기위해
스프링 프로젝트 내부에 또다른 프로젝트를 만들고 그 안에 배치를
만들고 스프링을 실행 시키면 동시에 실행이 되게 된다. 또한
실행이 완료가 되면 jar파일이 나눠져서 나오는데 이때 나온 jar파일을
기존의 프로젝트에는 배포에 필요한 jar을 업데이트 시키고,
젠킨스에 필요한 배치 jar파일은 해당 시간에 맞춰서 업데이트만 하고
그 이후엔 자동으로 업데이트가 되지 않게 한다.
https://4whomtbts.tistory.com/118
https://kim-jong-hyun.tistory.com/104
