Home Jmeter 성능 테스트
Post
Cancel

Jmeter 성능 테스트

Posted Apr 16, 2024 Updated Apr 16, 2024
By haedal-uni
27 min read

JMeter 성능 테스트

Message Broker를 변경하면서 얼마나 성능이 좋아졌는지 비교하기 위해 JMeter를 활용했다.



Test

성능 테스트 1

image

test할 sampler는 위와 같다.


순서대로 진행이 되기 위해서 특정 sampler 안에 timer를 넣었다.

View Results Tree를 보니 요청이 순서대로 실행이 되었지만

채팅방에 입장하지 않았는데 채팅 msg를 보내려고 하는 경우와 같이

실제로 서버에서 처리되는 속도에 의해서 순서가 바뀌어있었다.

따라서 timer를 추가하여 채팅방 입장 후에 send와 disconnect가 동작하게 했다.

Sampler 안에 Timer를 넣으면 해당 Sampler가 Timer에서 설정한 시간을 기다린 후에 동작한다.




1
2
3
4
5
6
7
8
9

Number of Threads (users) : 3000

Ramp-Up Period (in seconds) : 300 

Loop Count : 1

☑️ Same user on each iteration

☑️ Delay Thread creation until needed

사용자가 3000명이고 ramp-up 시간이 300초이며, 각 사용자는 루프(loop)를 1회 반복한다.

→ 300초 동안에 3000명의 사용자가 동시에 시작하고, 각 사용자가 한 번의 루프를 수행하므로 총 3000번의 요청이 진행된다.

*채팅방 send connection 타이머 설정(Thread Delay : 2 ms)
*채팅방 message 보내기 sampler 타이머 설정(Thread Delay : 2 ms)
*채팅방 disconnect sampler 타이머 설정(Thread Delay : 1 ms)



View Results Tree

image




Simple In-Memory Broker 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler300000160.49209743840919240.09.999866668444420.00.00.0
Debug Sampler30000020.21809681845965160.010.000400016000643.56327729671686870.0364.865
login3000977525011.4706831676815750.09.997100840756184.2370525047736162.294256540603225434.0
WebSocket Open Connection300011130.61467959133193940.010.000600036002162.30482578954737253.974847865871952236.0
send connect - WebSocket Single Write Sampler30000020.258672680342465930.010.0006667111140730.00.41018359557303820.0
subscribe - WebSocket Single Write Sampler30000010.195959179422654260.010.0006667111140730.01.08405664544302940.0
채팅방 입장 - WebSocket Single Write Sampler30000010.18377975949489110.010.0006667111140730.03.60375587539169250.0
채팅방 message 보내기 - WebSocket Single Write Sampler30000010.27638539919628330.010.0006667111140730.03.64282097973198170.0
채팅방 퇴장 - WebSocket Single Write Sampler30000010.27334634115389620.010.0006667111140730.03.68188608407227140.0
TOTAL2700011025030.7818509129914060.089.9652134507990310.10219733265637418.684181699742766114.985

  • Samples: 테스트 중에 수행된 작업의 총 수

  • Average: 모든 작업의 평균 응답 시간

  • Min: 가장 빨리 완료된 연결 작업의 시간

  • Max: 가장 오래 걸린 연결 작업의 시간

  • Std.Dev.: 응답 시간의 표준 편차를 말한다. 이는 응답 시간의 분산 정도를 나타내며, 값이 클수록 응답 시간의 변동이 크다는 것을 의미한다.

  • Error%: 작업 중 실패한 비율을 나타낸다. 0%가 나왔으므로 모든 연결이 성공했다는 의미이다.

  • Throughput: 단위 시간당 완료된 작업의 수 (여기서는 단위 시간이 sec다. 초당 ~개의 작업이 처리된다.)

  • Received KB/sec: 서버로 수신된 데이터의 평균 속도를 KB 단위로 나타낸다. 값이 높을 수록 성능이 좋다.

  • Sent KB/sec: 서버로 전송된 데이터의 평균 속도를 KB 단위로 나타낸다. 값이 높을 수록 성능이 좋다.

  • Avg.Bytes: 평균적으로 서버와 클라이언트 간에 교환되는 데이터의 크기를 나타낸다.



WebSocket Open Connection에서 최대 응답 시간이 다른 WebSocket Sampler에 비해 높게 나타난 것은

WebSocket 프로토콜로의 연결 설정에 시간이 소요된 결과로 보여진다.

HTTP와는 달리 WebSocket은 지속적인 양방향 통신을 제공하는 프로토콜이기 때문에 연결 설정에는 더 많은 리소스가 필요할 수 있다.

일반적으로 HTTP에서 WebSocket으로의 프로토콜 전환은 Socket의 생성 및 핸드쉐이크 과정을 포함하며,

이에는 추가적인 네트워크 라운드트립이 발생할 수 있다. 이 과정에서 최대 응답 시간이 발생할 수 있다.

따라서 66초의 최대 응답 시간은 WebSocket 연결 설정에 소요된 시간으로 해석될 수 있다.




image

login을 제외한 나머지 sampler들의 응답 시간이 모두 0으로 나타나고 있다.

WebSocket과 같은 비동기 작업은 응답 시간이 0으로 표시될 수 있고

서버와의 통신에서 매우 적은 시간이 소요되는 경우 응답시간이 거의 없다고 볼 수 있다.




image

응답 시간(ms)은 샘플러가 실행되고 완료되는 데 걸리는 시간을 나타낸다.

값이 작을수록 해당 샘플러의 응답 시간이 짧다는 것을 의미하고 값이 클수록 응답 시간이 긴 것을 나타낸다.

그래프가 없다는 것은 실행되고 완료되는 시간이 너무 빨라서 측정이 불가능해서 나타나는 결과일 가능성이 높다.




RabbitMQ 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler300000140.461770024531211350.010.00.00.00.0
Debug Sampler30000010.19906001328465970.010.0004666884454623.5731289856026620.0365.8713333333333
login3000997526014.0658164000530290.09.9974006758242864.23717958330834052.294325350408894434.0
WebSocket Open Connection300011140.59754600008888250.010.0010334401221462.30492567565315073.9750201270797985236.0
send connect - WebSocket Single Write Sampler30000010.250598394958059470.010.0011334617923350.00.41020273964382630.0
subscribe connect - WebSocket Single Write Sampler30000010.17688382879418030.010.0011334617923350.01.21107475513891560.0
subscribe send - WebSocket Single Write Sampler30000010.161107279647927650.010.0011334617923350.01.1817745594500710.0
subscribe disconnect - WebSocket Single Write Sampler30000010.1455926585450730.010.0011334617923350.01.24037495082776040.0
채팅방 입장 - WebSocket Single Write Sampler30000010.164015920636449870.010.0011334617923350.03.6136908016241840.0
채팅방 message 보내기 - WebSocket Single Write Sampler30000010.27025831264839120.010.0012001440172820.03.6527820838500620.0
채팅방 퇴장 - WebSocket Single Write Sampler30000010.28280951579149920.010.0012001440172820.03.69184927191262970.0
TOTAL330009026028.8787596539656660.0109.9626127116780310.11249274205103721.2623020672971294.17012121212122


image


image



성능 차이가 크게 나지 않는 이유에 대해서 분석해본다.

  • Overhead 및 Latency:

    사용자 수가 증가하고 Ramp-Up 기간이 길어질수록

    RabbitMQ는 네트워크 트래픽과 메시지 브로커에서의 처리에 더 많은 오버헤드를 발생시킬 수 있다.

    이로 인해 RabbitMQ의 성능이 감소할 수 있다.

    반면에 Simple In-Memory Broker는 네트워크 오버헤드가 없으며

    메모리 내에서 메시지를 처리하므로 이러한 성능 저하가 없을 수 있다.


  • 리소스 활용

    RabbitMQ는 메시지를 브로커로 전송하고 처리하기 위해 시스템 리소스를 사용한다.

    따라서 더 많은 사용자 및 스레드가 활성화되면 RabbitMQ의 리소스 사용량이 증가하여 성능에 영향을 줄 수 있다.

    Simple In-Memory Broker는 메모리 내에서만 작동하므로 리소스 사용량이 상대적으로 적고,

    따라서 더 많은 사용자 및 스레드를 다룰 때에도 성능이 유지될 수 있다.


  • 최적화:

    Simple In-Memory Broker는 단순하고 경량화되어 있어서 작은 규모의 테스트에서는 RabbitMQ보다 효율적일 수 있다.

    특히 사용자 수가 적고 메시지 처리가 빈번하지 않은 경우에는 Simple In-Memory Broker가 더 나은 성능을 보일 수 있다.


이러한 이유로 인해 특정 조건에서는 Simple In-Memory Broker가 RabbitMQ보다 성능이 우수하게 나타날 수 있다.

그러나 대규모 및 분산 환경에서는 RabbitMQ의 더 나은 확장성과 성능이 더 중요해질 수 있다.


1
2
3
4
5
6
7
8
9
10
11
12
13

오버헤드(Overhead)란 어떤 작업을 수행하기 위해 필요한 추가적인 자원 또는 처리 과정을 말한다.

ex) 편지를 보내는 상황

내가 직접 친구에게 전달하는 경우 :
추가 비용이 발생하지 않는다. → 오버헤드 x

편지를 우편 서비스를 통해 보내는 경우 : 
우편 봉투를 작성하고 우편 배달 서비스를 이용하는데 소요되는 시간과 비용이 추가된다 → 오버헤드

직접 친구에게 보내는 과정에서 1시간이 소요되었는데
우편 서비스를 이용해 보내게 되면서 24시간이 소요되었다면
오버헤드는 24-1인 23시간이라고 보면 된다.





성능 테스트 2

login 후 → 채팅(conncet → send → disconnect)의 흐름을 순서대로 진행시키다 보니 큰 차이를 느끼지 못해서

이번에는 채팅 메시지를 보내는 SEND 과정만 loop로 돌리고 차이를 비교해봤다.

image


1
2
3
4
5
6
7
8
9
10
11

Number of Threads (users) : 1

Ramp-Up Period (in seconds) : 1 

Loop Count : 1

☑️ Same user on each iteration

☑️ Delay Thread creation until needed

- Loop Controller의 Loop Count : 30




Simple In-Memory Broker 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler11414140.00.071.428571428571430.00.00.0
login19191910.00.010.9890109890109894.6574519230769232.5218921703296706434.0
WebSocket Open Connection14440.00.0250.057.617187599.365234375236.0
send connect - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 입장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 message 보내기 - WebSocket Single Write Sampler300010.249443825784929430.015000.00.05478.5156250.0
채팅방 퇴장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
TOTAL37309114.8524272290624120.0327.433628318584065.790237831858407110.299709623893818.10810810810811



RabbitMQ 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler11313130.00.076.923076923076920.00.00.0
login18888880.00.011.3636363636363654.8162286931818182.6078657670454546434.0
WebSocket Open Connection11110.00.01000.0230.46875397.4609375236.0
send connect - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe connect - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe send - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe disconnect - WebSocket Single Write Sampler11110.00.01000.00.0124.02343750.0
채팅방 입장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 message 보내기 - WebSocket Single Write Sampler300000.00.030000.00.010957.031250.0
채팅방 퇴장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
TOTAL39208813.9990607367838450.0364.48598130841126.114924065420561118.8668224299065517.17948717948718



  • Simple In-Memory Broker 적용
    • 채팅 메시지를 보내는 과정에서 평균적으로 15,000개의 메시지가 전송되었다.
    • 채팅방 메시지 최대 응답 시간은 1ms다.
    • 전체 평균 응답 시간은 약 3ms이며, 최대 응답 시간은 91ms다.
  • RabbitMQ 적용
    • 채팅 메시지를 보내는 과정에서 평균적으로 30,000개의 메시지가 전송되었다.
    • 채팅방 메시지 최대 응답 시간은 0ms다.
    • 전체 평균 응답 시간은 약 2ms로 더 줄어들었고, 최대 응답 시간은 88ms다.
  • 결과 분석:
    • RabbitMQ를 사용한 경우에는 채팅방 메시지 평균 전송량이 두 배 이상으로 매우 높은 처리량을 보였다.
    • RabbitMQ를 사용한 경우에는 전체 평균 응답 시간이 더 짧았으며, 최대 응답 시간도 감소하여 효율성이 향상되었다.
    • 또한, RabbitMQ를 사용한 경우 채팅방 메시지의 평균 전송량이 약 5478에서 10957로 상당히 높아졌으며,
      채팅방 메시지의 응답 시간도 유의미하게 낮아졌다.
      따라서 RabbitMQ가 더 많은 부하를 처리하는 동시에 효율적으로 동작하는 것으로 나타났다.





성능 테스트 3

이번 성능 테스트에서는 성능 테스트 2에 비해 Number of Threads와 Ramp-Up Period를 늘려 테스트를 진행했다.

1
2
3
4
5
6
7
8
9
10
11

Number of Threads (users) : 5000

Ramp-Up Period (in seconds) : 600 

Loop Count : 1

☑️ Same user on each iteration

☑️ Delay Thread creation until needed

- Loop Controller의 Loop Count : 30


Simple In-Memory Broker 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler500000320.61409784236715890.08.3334444459259470.00.00.0
login50001157330724.936949804657330.08.3321112903440843.53138310547786331.9121544465145113434.0
WebSocket Open Connection500010511.0628011290923620.08.3338472539139931.92069135930049043.312378742522456236.0
send connect - WebSocket Single Write Sampler50000010.215030323442997220.08.3338889259283950.00.34181966297753180.0
subscribe - WebSocket Single Write Sampler50000010.16892495375165860.08.3338889259283950.00.90338053786919130.0
채팅방 입장 - WebSocket Single Write Sampler50000010.16611273280516460.08.3338889259283950.03.01126845956397070.0
채팅방 message 보내기 - WebSocket Single Write Sampler1500000060.176408245713049250.0250.016251056318650.091.314529194397640.0
채팅방 퇴장 - WebSocket Single Write Sampler50000010.171685293487823240.08.3339028166924760.03.07638209444312060.0
TOTAL1850003030719.2105493117907750.0308.26859692797855.4513291792057103.8437527077647118.10810810810811


image


image



RabbitMQ 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler500000150.44091522994788920.08.333347222245370.00.00.0
login50001077219224.7333991768215920.08.3322917968587263.53145960921551441.9121958713494145434.0
WebSocket Open Connection500010180.62178375662283080.08.3333611112037041.92057931859772853.3121855197850656236.0
send connect - WebSocket Single Write Sampler50000010.212492917529032020.08.3333611112037040.00.34179801432671440.0
subscribe connect - WebSocket Single Write Sampler50000010.169481090390639160.08.3333611112037040.01.00911794705982350.0
subscribe send - WebSocket Single Write Sampler50000010.16382380779361710.08.3333611112037040.00.98470380317934380.0
subscribe disconnect - WebSocket Single Write Sampler50000010.152425588402997470.08.3333611112037040.01.0335320909403030.0
채팅방 입장 - WebSocket Single Write Sampler50000050.1824498835296970.08.3333611112037040.03.01107774525915060.0
채팅방 message 보내기 - WebSocket Single Write Sampler1500000060.1792580481379350.0250.00.091.308593750.0
채팅방 퇴장 - WebSocket Single Write Sampler50000010.17705998983395430.08.3333611112037040.03.07618212894042960.0
TOTAL1950002019217.488325779180170.0324.94854981294635.451610786625451105.9728043059848817.17948717948718


image


image



RabbitMQ를 사용한 경우와 Simple In-Memory Broker를 사용한 경우 모두 비슷한 결과가 나타났다.

전반적으로 동일한 성능을 보여주었으며, 특별히 큰 차이를 보이지 않았다.





성능 테스트 4

이번 테스트에서는 성능 테스트 2의 Loop Count를 3배로 증가시켰다.

1
2
3
4
5
6
7
8
9
10
11

Number of Threads (users) : 1

Ramp-Up Period (in seconds) : 1 

Loop Count : 1

☑️ Same user on each iteration

☑️ Delay Thread creation until needed

- Loop Controller의 Loop Count : 90

Simple In-Memory Broker 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler12020200.00.050.00.00.00.0
login19393930.00.010.752688172043014.5572916666666672.467657930107527434.0
WebSocket Open Connection11110.00.01000.0230.46875397.4609375236.0
send connect - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 입장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 message 보내기 - WebSocket Single Write Sampler900010.179505493571150140.012857.1428571428570.04695.8705357142850.0
채팅방 퇴장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
TOTAL9710939.5851454493477830.0782.2580645161295.276587701612903277.241368447580676.907216494845361



RabbitMQ 적용

LabelSamplesAverageMinMaxStd.Dev.Error%ThroughputReceived KB/secSent KB/secAvg.Bytes
JSR223 Sampler11919190.00.052.6315789473684250.00.00.0
login11261261260.00.07.9365079365079373.36371527777777771.8213665674603174434.0
WebSocket Open Connection14440.00.0250.057.617187599.365234375236.0
send connect - WebSocket Single Write Sampler11110.00.01000.00.041.0156250.0
subscribe connect - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe send - WebSocket Single Write Sampler10000.00.00.00.00.00.0
subscribe disconnect - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 입장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
채팅방 message 보내기 - WebSocket Single Write Sampler900010.179505493571150140.015000.00.05463.86718750.0
채팅방 퇴장 - WebSocket Single Write Sampler10000.00.00.00.00.00.0
TOTAL991012612.7209941223182370.0626.58227848101264.1411194620253164218.626384493670886.767676767676767



  • Simple In-Memory Broker 적용
    • 채팅 메시지를 보내는 과정에서 평균적으로 약 12,857.14 샘플/초의 메시지가 전송되었다.
    • 채팅방 메시지의 최대 응답 시간은 1ms로 매우 빠른 응답 속도를 보였다.
    • 전송 속도는 약 4,695.87 KB/sec이다.
  • RabbitMQ 적용
    • 채팅 메시지를 보내는 과정에서 평균적으로 약 약 15,000 샘플/초의 메시지가 전송되었다.
    • 채팅방 메시지의 최대 응답 시간은 0ms로 매우 빠른 응답 속도를 보였다.
    • 전송 속도는 약 5,463.87 KB/sec이다.
  • 결과 분석
    • RabbitMQ를 사용한 경우에는 채팅 메시지 전송량이 증가했다.
      이는 RabbitMQ가 더 많은 부하를 처리할 수 있다는 것을 시사한다.
    • Sent KB/sec는 시스템이 단위 시간당 전송하는 데이터 양을 나타낸다. RabbitMQ의 Sent KB/sec 값이 더 높게 나타나면서 채팅 메시지를 더 빠르게 처리하고 전송한다는 것을 시사한다.
    • RabbitMQ를 사용한 경우에는 평균 응답 시간이 더 짧았고, 최대 응답 시간도 감소하여 효율성이 향상되었다.
    • 따라서, RabbitMQ가 채팅 시스템의 성능과 안정성을 향상시킬 수 있는 좋은 대안이 될 수 있음을 시사한다.





결론

Simple In-Memory Broker 적용 vs. RabbitMQ 적용

Throughput은 시스템이 단위 시간당 처리할 수 있는 작업의 양을 나타낸다.

RabbitMQ를 사용한 경우에는 채팅 메시지 전송량이 두 배 이상으로 증가했다.

이는 RabbitMQ가 더 많은 부하를 처리할 수 있다는 것을 시사한다.

또한, RabbitMQ를 사용한 경우에는 평균 응답 시간이 더 짧아지고, 최대 응답 시간도 감소하여 효율성이 향상되었다.

Sent KB/sec를 보면서 RabbitMQ를 사용한 경우에는 데이터 전송 속도가 더 빠르다는 것을 알 수 있다.

높은 Sent KB/sec는 시스템이 단위 시간당 더 많은 데이터를 처리하고 전송한다는 것을 의미하므로,

RabbitMQ를 사용한 경우에는 데이터가 더 빠르게 전송되며, 따라서 시스템의 성능이 향상되었다고 볼 수 있다.



성능 테스트 2 vs. 성능 테스트 3:

성능 테스트 3에서는 더 많은 사용자를 시뮬레이션하고, 더 긴 Ramp-Up Period를 사용하여 테스트를 진행했다.

전반적으로 동일한 성능을 보여주었으며, 특별히 큰 차이를 보이지 않았다.



성능 테스트 2 vs. 성능 테스트 4:

성능 테스트 4에서는 Loop Count를 3배로 늘려서 테스트를 진행했다.

이 결과, RabbitMQ를 사용한 경우에는 평균 응답 시간이 더 짧아지고, 최대 응답 시간도 감소하는 것을 확인할 수 있었다.





JMeter를 적용하면서 수정한 코드

roomId를 갖고오는 메소드와 권한 갖고오는 메소드의 key가 같아서

roomId를 갖고오려고 실행했으나 권한이 출력되는 경우가 생겼다.

따라서 key값을 다르게 적용해야한다.


변경 전

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public void addRedis(ChatMessage chatMessage) {
    long expireTimeInSeconds = 24 * 60 * 60;
    long creationTimeInMillis = System.currentTimeMillis();
    long remainingTimeInSeconds = expireTimeInSeconds - ((System.currentTimeMillis() - creationTimeInMillis) / 1000);
    redisTemplate.opsForValue().set(chatMessage.getSender(), chatMessage.getRoomId(), remainingTimeInSeconds, TimeUnit.SECONDS);
}

public String getRedis(String nickname) {
    return redisTemplate.opsForValue().get(nickname);
}

public void deleteRedis(String nickname) {
    redisTemplate.delete(nickname);
}

public void addAuth(ChatMessage chatMessage){
    long expireTimeInSeconds = 24 * 60 * 60;
    long creationTimeInMillis = System.currentTimeMillis();
    long remainingTimeInSeconds = expireTimeInSeconds - ((System.currentTimeMillis() - creationTimeInMillis) / 1000);
    redisTemplate.opsForValue().set(chatMessage.getSender(), chatMessage.getAuth(), remainingTimeInSeconds, TimeUnit.SECONDS);
}

public String getAuth(String nickname){
    return redisTemplate.opsForValue().get(nickname);
}


변경 후

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public void addRoomId(ChatMessage chatMessage) {
    long expireTimeInSeconds = 24 * 60 * 60;
    long creationTimeInMillis = System.currentTimeMillis();
    long remainingTimeInSeconds = expireTimeInSeconds - ((System.currentTimeMillis() - creationTimeInMillis) / 1000);
    redisTemplate.opsForValue().set("getRoomId - " + chatMessage.getSender(), chatMessage.getRoomId(), remainingTimeInSeconds, TimeUnit.SECONDS);
}

public String getRoomId(String nickname) {
    return redisTemplate.opsForValue().get("getRoomId - " + nickname);
}

public void deleteRoomId(String nickname) {
    redisTemplate.delete("getRoomId - " + nickname);
}

public void addAuth(ChatMessage chatMessage){
    long expireTimeInSeconds = 24 * 60 * 60;
    long creationTimeInMillis = System.currentTimeMillis();
    long remainingTimeInSeconds = expireTimeInSeconds - ((System.currentTimeMillis() - creationTimeInMillis) / 1000);
    redisTemplate.opsForValue().set("auth - " + chatMessage.getSender(), chatMessage.getAuth(), remainingTimeInSeconds, TimeUnit.SECONDS);
}

public String getAuth(String nickname){
    return redisTemplate.opsForValue().get("auth - " + nickname);
}
Project, 성능테스트
Monitoring
This post is licensed under CC BY 4.0 by the author.
Recently Updated
Contents