Page History

...

메시지 전송에의해서만, 처리가 되기때문에 확장및 동시성처리에 유연해집니다유연해지며 블락이 되지 않습니다.

Actor2는 MessageA 처리중, MessageB요청을 받게되며 처리후 다음 메시지를 처리합니다.

블락킹 모델과 다른점은 Actor3는 MessageB를 요청하고 대기상태에 빠질필요가 없다는 것입니다.

위 그림을 보면, 이러한 의문을 가질수 있습니다.  액터하나당? Thread를 하나사용하는것인가?

그러면  액터수 생성에 제한이 있지 않는가? 실제 아무일을 하지 않는 액터는 스레드를 점유하지 않으며

동시 처리가능수에대한 제한도 가능합니다 않습니다. ( dispatcher가 액터들을 스레드풀에의해 효율적으로 관리함)

만약 어떠한 액터가 블락킹(처리시간이 많이걸리는)을 많이 발생하는 처리 시간이 많이걸리는 액터라고 가정하면..,

빠르게 작동되는 액터와 스레드사용 전략을 분리할 필요가 있습니다.

AKKA에서는  이러한 문제를 복잡한 스레드 모델이 아닌 튜닝가능한 옵션으로 해결하려고 시도합니다.

멀티스레드를 멀티스레드 측정을 위해 Tace하거나 중단을 통해 작동의 연관성을 찾는것은 어렵기때문에, 스레드 프로파일러 시각화 툴의 도움을 받습니다.

만약 위 스레드를 자신이 작성하고, 내부적으로 제한 처리를 하고 메시지큐를 처리 한다고 하면 그러한 코드로 인해 서비스 코드의 복잡성이 증가할것입니다.

AKKA에서는 단지 튜닝을 위한 목적으로 ThreadView를 활용합니다.  

목적과 성능에따라 액터를 관리할 dispatcher를 분리하게되면 Actor의 성능에 대한 문제 파악이 용이해집니다.

...