Page History
Info |
---|
단일기기 단일 액터의 전송 능력을 확인하기 위해 닷넷코어 AKKA.net을 이용하여 전력을 소모하고 돈 안되는 성능 테스트를 진행해보겠습니다.성능을 극단적으로 올려 확인하기보다, 측정가능한 기초적인 방식을 도입해보겠습니다이용하여 가장 실플하게 부하를 줄수있는 액터설계와, 측정가능한 녀석으로 만들어보겠습니다. |
무한반사 액터설계
무한 반사 액터의 컨셉이며, 이 컨셉에서 단일장비에서 얼마나 많은 메시지를 처리하는지확인하기위해 무한반사 액터를 다음과 같이 설계하였습니다가장 심플하게 부하를 줄수 있어서 채택하였습니다.
- 단일 액터는 순차성이 보장되기때문에, 하나의 액터는 하나의 메시지만 처리한다처리합니다.
- 메시지를 상대에게 재 전송한다. 받은녀석은 또 재전송한다 ( 무한 )무한메시지는 n개 추가가능...전송하며, 상대는 또 재전송합니다.
- 메시지는 n개 추가가능하며, 메시지를 늘려봅니다.
성능에영향을 주는 경우의 수 = 액터수(탁구대1쌍) * 메시지수(탁구공)
실제 작동모습
액터두개를 만들고 위와같이 작동을 시켜, Tick(탁구채에 맞은수를 모두 카운팅)
의 TPS를 측정합니다. 탁구공이 상대편에 전달되는 시간이 짧으면 짧을수록 많은 수가 처리되며
CPU를 최대한 활용해서 0에가깝게 작동되겠지만...물리적으로 0이 될순없을것같습니다. ( 더 깊이들어가면 수학이 될것같습니다.)
정확하게 위와동일하게 작동하는 액터를 만들어보겠습니다.
성능테스트기를 어떻게 구현하고 검증하였는지 간략하게 살펴보겠습니다메시지 발생수(틱톡)를 카운팅하여, 탁구대수와 공의수를 조절하여
TPS를 최대한 끌어올려보는것이 이 실험의 주요 목표입니다.
무한반사 액터구현
Code Block | ||||
---|---|---|---|---|
| ||||
using Akka.Actor; using Akka.Event; using Akka.Monitoring; namespace AkkaDotBootApi.Actor { public class InfiniteMessage { public string Message { get; set; } public uint Count { get; set; } } public class InfiniteReflectionActor : ReceiveActor { private IActorRef ReplyActor; private readonly ILoggingAdapter logger = Context.GetLogger(); public InfiniteReflectionActor() { ReceiveAsync<IActorRef>(async actorRef => { ReplyActor = actorRef; }); ReceiveAsync<InfiniteMessage>(async infiniteMessage => { Context.IncrementCounter("akka.infinite.metric"); // <-- 요녀석이 성능카운터 측정기, 지정된이름으로 메시지당 1증가합니다.(관찰자를 등록함으로 성능이 미비하게 희생될수 있으나,게의치 않겠습니다.) var reply = new InfiniteMessage { Message = infiniteMessage.Message, Count = ++infiniteMessage.Count }; if(reply.Count % 50000 == 0) // <-- 작동잘하는지 확인하기위해 5만건당 로그를 찍습니다.( 참고로 콘솔창은 해당 TPS를 못 따라가기때문에 건수마다 찍으면 안됩니다위험합니다.) { logger.Info($"Count:{reply.Count}"); } ReplyActor.Tell(reply); // 카운팅 1증가된 메시지를 되돌려줍니다.(상대편이 받고 다시 받게됩니다. - 무한반사) }); } } } |
...
닷넷의 일반적인 스레드풀을 사용하느냐? TPL을 사용하느냐? 또는 forkJoin을 사용하느냐 튜닝이가능합니다.
액터모델의 개수가 작고 단순해서 그런지여기서는, 튜닝값을 이리저리 바꿔도 성능에 큰 차이가 없습니다.오히려 너무많은 무한 액터를 생성하면(5쌍이상) 속도가 저하됩니다없음을 확인하였습니다.
참고링크 : https://getakka.net/articles/actors/dispatchers.html
...
탁구대와 공개수를 늘려보면서, 최대 처리량 임계치를 계속 찾아보았습니다.
M = 백만
최대 발견 임계치 : 3백만개 / 30초 , 10만/sec
CPU 메모리
CPU가 낮은 구간은 테스트를 중단하고 튜닝옵션을 바꾸고 있는중입니다.
...
- 개체별 합리적으로 호출하는지?
- 해당 개체는 성능적으로 효율적으로 작동하는 개체인지?
- 메모리 누수여부?
성능 결과
- 단일기기 안정적으로 초당 10만건 처리가 가능
- 기기당 분당 4~6백만건의 메시지 처리
- 초당처리 10만건정도
- GC는 일어나지만 지속 테스트되는동안 GC는 많이 발생하지만,메모리 누수는 없음
도전과제
Warning |
---|
만족할만한 성능이 나온것은 아닌거 같으며 기기당 초당 5천만의 목표치에 도달하지 못하였습니다. 핑퐁테스트가 컨텍스트전환으로 인해 성능적으로 불리한것인지? GC발생을 조절해야하는지? 성능을 올리기위한 변종실험은 계속됩니다. ( 우선 측정가능한 상태로 만든것에 의미를 두었습니다 .)측정가능한 상태와, 10만개처리가능한것으로 마무리를 하였습니다. ) |
git : https://github.com/psmon/AkkaDotModule/blob/master/AkkaDotBootApi/Actor/InfiniteReflectionActor.cs
범위 : 30초구간
단위 : M ( 백만)
1차실험 : 디버깅모드 : 2.17