dev 130

버퍼풀

빈번한 객체 사용에 자주 사용되는 object pool pattern은 버퍼도 예외가 아니다 목적은 메모리를 할당하고 해제하는 비용 즉, 오버헤드를 줄임으로서 성능향상을 꾀한다고 볼 수 있다 garbage collection이 동작하는 언어에서 더욱 빛을 발하게 되는데 객체의 재사용은 gc에게 일을 적게 주기 때문이다 통신시 수신되는 데이터를 저장하기 위해서 버퍼를 사용할때 효율적인 방법을 생각해보자 1:1과 1:n 상황에 따라 다를것이다 1:1은 수신버퍼가 1개가 필요할것이고 1:n은 n개가 필요할 것이다 수신버퍼는 그렇지만 데이터를 처기하기위해 추가적인 버퍼가 필요한데 이과정은 케이스 바이 케이스 작은 메모리의 잦은 할당과 해제 정확히 객체풀패턴이 필요한 상황이 된다

dev 2017.05.05

Ring buffer(Circular buffer) 고찰

링버퍼 구현체를 찾아보면, 다양한 방법들로 구현이 되어 있다. 이미 하이레벨 언어에서는 기본적으로 지원해주기에, 직접 구현해서 쓸 일을 별로 없는 것 단일 배열로 구현한 형태를 기준으로_HEAD와 _TAIL을 가리키는 포인터 형태가 일반적이다.HEAD는 PUT할 위치를 가르킨다.TAIL은 GET할 위치를 가르킨다.그러면, 내부 멤버변수는 배열, HEAD, TAIL 총 3개, 여기에 SIZE 를 추가하면 총 4개다. 데이터의 크기를 담을 SIZE 변수가 있으면, 비거나, 꽉찬 상태를 체크하기가 쉽다. SIZE변수가 없는 경우는 어떨까?? HEAD와 TAIL로 사이즈를 구하는 것은 불가능 하다. 비었을 경우나, 꽉찬 경우 모두 HEAD == TAIL이 성립하기 때문이다. 이것을 해결한 구현방법은 배열 생성시..

dev 2017.04.19

IO(input/output) model

IO 모델 전통적인 IO 모델(Blocking I/O)blocking io를 사용하는 방법으로, Multi-Threaded Request-Response 형태이다. concurrent 요청을 처리하기 위해서, 쓰레드를 관리해 사용한다. IO가 시작되었을때, 어플리케이션이 blocked, IO가 끝날 때까지 대기 프로세스 단계클라이언트가 서버로 요청서버는 내부적으로 한정된 스레드 풀을 유지 관리하여 클라이언트 요청에 서비스를 제공서버는 무한루프에 있으며, 클라이언트 요청을 기다림서버가 다수의 요청을 받음서버가 하나의 요청을 선택(SELECT)쓰레드풀로 부터 하나의 쓰레드를 선택요청을 쓰레드에 할당쓰레드에서 bloking io를 처리(ACCEPT, RECV) 및 응답준비쓰레드는 응답을 서버로 보냄서버는 다시..

dev 2017.04.03

Modern Data Binding

데이터 바인딩 그러니까, 보이지 않는 Data를 보이는 View에 할당 시키는 과정 이런 개념은 사용자 인터페이스가 존재하는 모든 곳에서 사용되어지고 있다. 하고싶은 포스팅은 이것들의 기초적인 방법과 개념에 대한 것이다. 단순 참조가장 심플한 방법으로써, View가 계속해서 Data를 참조하고 있는 구조이다.이는 View가 Render가 될 때, 해당 데이터를 직접 표시한다. View - Data Pros데이터 변경되면, 즉시 반영된다.(Auto Refresh)Cons데이터는 무조건 메모리에 있어야 한다. 풀링(데이터 요청)View에서 Data가 필요할 때, Request을 통해서, 데이터를 가져오는 방법 View - Request/Response - Data 요청/응답에 대한 오버헤드는 없다고 가정 P..

dev 2017.03.14