Programming Server-Side Applications

Programming Server-Side Applications for Windows 2000

Chapter One: Te Discipline of Service Development

Scalability and Perfomance

• 크리티컬 섹션을 쓸 수 있으면 그걸 써라. (Mutex를 이용한 라킹: 1000 CPU Clock. Critical Section을 이용한 라킹: 100 CPU Clock)
• Scalability: 싱글 머신에서 실행되는 서버의 경우, RAM을 두 배 늘렸다고 생각했을 때, 성능이 2배 개선되면 scalability 가 좋은 것이다. 성능이 0.2 배 개선되면 scalability 가 나쁜 것이다.

서버 프로그래밍을 할 때 염두해 두어야 하는 것:

• user-mode 와 kernel-mode 간의 전환이 잘 일어나지 않게 짜고 있는가?
• cache의 용량을 초과하여 메모리를 억세스하고 있지는 않은가?
• 변수를 적절히 정렬하고 있는가?
• 시스템 자원 소모를 줄이기 위해서 스레드질을 하고 있는가?
• 쓸모없는 컨텍스트 스위칭을 줄이기 위해 실행되는 스레드의 수를 줄이고 있는가?
• device I/O 작업이 완료되기를 기다리는 동안 스레드가 유용한 일을 하고 있는가?
• Windows 함수의 퍼포먼스를 향상하기위해 ANSI 문자열 대신 유니코드를 쓰고 있는가?
• Windows 가 제공하는 (멋진?) 기능을 잘 사용하고 있는가?

Chapter Two: DEVICE I/O AND INTERTHREAD COMMUNICATION

• I/O completion port : 스레드에서 i/o request 가 처리되기를 기다리는 동안, 마냥 기다리는 것이 아니라 쓸법한 일을 할 수 있도록 하기 위해, 즉 멀티스레딩 성능을 향상 시키기위해 Microsoft가 개발한 i/o 처리 기술.

• Windows 2000 kernel 에 포함된 job object 는 i/o completion port 와 상호 협동하며 i/o 관련 notification을 수행해 준다.

• I/O completion port 는 본디 i/o device 와 관련해서만 쓰이는 것이었으나, 이제는 좀 더 큰 규모로 발전하여 interthread communication and device I/O 를 위한 메커니즘이 되었다.

Opening and Closing Devices

• 이 책에서 정의한 device: 파일(File, Directory, Logical disk drive, Physical disk drive), 포트(Serial port, Parallel port), 통신(Mailslot, Named Pipe, Anonymous pipe, Socket), Console

• Device Open:

Device	Creational Functiion
File	CreateFile("c:\test.txt")
Directory	CreateFile("c:\Program Files", ..., FILE_FLAG_BACKUP_SEMANTICS)
Logical disk drive	CreateFile( "\\.\C:" )
Physical disk drive	CreateFile( "\\.\PHYSICALDRIVE0" )
Serial Port	CreateFile( "COM1" )
Parallel port	CreateFile( "LPT1" )
Mailslot server	CreateMailslot( "\\.\mailslot\mailslotname" )
Mailslot client	CreateFile( "\\servername\mailslot\mailslotname" )
Named pipe server	CreateNamedPipe( "\\.\pipe\pipename" )
Named pipe client	CreateFile( "\\servername\\pipe\pipename" )
Anonymous pipe	CreatePipe client and server
Socket	socket(), accept(), AcceptEx()
Console	CreateConsoleScreenBuffer(), or GetStdHandle()

• Device Close : CloseHandle( handle ) 또는 closesocket( sock ) (소켓의 경우는 CloseHandle로 닫으면 안됨)

• 핸들의 타입을 알아내려면 : DWORD GetFileType( HANDLE hDevice )

A Detailed Look at CreateFile

• File 이외의 device 를 열때에는 dwCreationDistribution 파라미터에 OPEN_EXISTING 을 주어야만 해.

• CreateFile Cache Flags
  • FILE_FLAG_NO_BUFFERING : 시스템의 cache manager 가 해당 파일을 캐쉬하지 않도록 함. (이 경우 시스템은 사용자가 제공한 버퍼에 직접 데이터를 담그기 때문에 offset 이나 버퍼사이즈는 반드시 sector size의 정수배여야 한다) 단, 엄청나게 큰 사이즈의 파일을 여는 경우에는 이 플랙을 사용하는 것이 좋다.
  • FILE_FLAG_SEQUENTIAL_SCAN / FILE_FLAG_RANDOM_ACCESS : 캐쉬매니져가 앞으로 읽을 내용을 미리 읽음 / 읽지 않음
  • FILE_FLAG_WRITE_THROUGH : read cache 는 동작, write cache 는 작동하지 않고 디스크에 바로 씀. (장애에 의한 데이터 손실을 최대한 막을 수 있음.)

• Miscellaneous CreateFile Flags
  • FILE_FLAG_DELETE_ON_CLOSE : 훌륭하군. 모든 핸들이 close 되면 파일 삭제.
  • FILE_FLAG_BACKUP_SEMANTICS : 백업권한을가진 사용자는 오픈가능. 디렉토리를 오픈가능
  • FILE_FLAG_POSIX_SEMANTICS : 파일명을 대소문자 구별함.
  • FILE_FLAG_OPEN_REPARSE_POINT : 파일의 repase attribute 를 작동시키지 않고 파일을 염. (비추천)
  • FILE_FLAG_OPEN_NO_RECALL : 파일의 data 를 offline storage(TAPE등) 에 만들도록 함.
  • FILE_FLAG_OVERLAPPED : device 에 asynchronous 하게 접근할 것임을 지정함. (기본값은 synchronous 함) 이것이야말로, 우리가 서버 퍼포먼스를 향상시키기 위해 써야 하는 것임!!

• File Attribute Flags
  • FILE_ATTRIBUTE_HIDDEN 등등
  • FILE_ATTRIBUTE_TEMPORARY : 메모리에서 파일을 조작. 파일이 더 이상 필요없게 되면 디스크에 씀. (FILE_FLAG_DELETE_ON_CLOSE 와 함께 쓰면 좋음)
  • 외 다수

• hfileTemplate 인자 - 이미 열려 있는 파일의 핸들을 여기에 제공하면, 그 파일의 dwFlagsAndAttrs 속성을 빌려 씀.

• CreateFile 이 실패하면 INVALID_HANDLE_VALUE 가 리턴됨 (NULL이 리턴되는 것이 아님에 주의!!)

Working with File Devices

• 윈도우즈의 파일사이즈의 최대크기는 사실 64-bit (16ExaByte) 이다.

Getting a File's Size

• BOOL GetFileSizeEx( HANDLE hfile, PLARGE_INTEGER pliFileSize )
• LARGE_INTEGER, ULARGE_INTEGER, LONGLONG, ULONGLONG
• DWORD GetCompressedFileSize( PCTSTR pszFileName, PDWORD pdwFileSizeHigh )

Positioning a File Pointer

• 알아두면 좋은 API들:
  • BOOL ReadFile( HANDLE hFile, LPVOID lpBuffer, DWORD nNumberOfBytesToRead, LPDWORD lpNumberOfBytesRead, LPOVERLAPPED lpOverlapped );
  • BOOL DuplicateHandle( HANDLE hSourceProcessHandle, HANDLE hSourceHandle, HANDLE hTargetProcessHandle, LPHANDLE lpTargetHandle, DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD dwOptions )
  • BOOL SetEndOfFile( HANDLE hFile ) : 파일의 크기를 간단하게 늘이거나 줄일 수 있다.

• BOOL SetFilePointerEx( HANDLE hFile, LARGE_INTEGER liDistanceToMove, PLARGE_INTEGER lpNewFilePointer, DWORD dwMoveMethod ) : 파일 포인터를 움직인다.

Performing Synchronous Device I/O

BOOL ReadFile(
  HANDLE hFile,                // handle to file
  LPVOID lpBuffer,             // data buffer
  DWORD nNumberOfBytesToRead,  // number of bytes to read
  LPDWORD lpNumberOfBytesRead, // number of bytes read
  LPOVERLAPPED lpOverlapped    // overlapped buffer
);

BOOL WriteFile(
  HANDLE hFile,                    // handle to file
  LPCVOID lpBuffer,                // data buffer
  DWORD nNumberOfBytesToWrite,     // number of bytes to write
  LPDWORD lpNumberOfBytesWritten,  // number of bytes written
  LPOVERLAPPED lpOverlapped        // overlapped buffer
);

BOOL FlushFileBuffers(
  HANDLE hFile  // handle to file
);

Basics of Asynchronous Device I/O

• FILE_FLAG_OVERLAPPED 로 생성한 hFile 을 가지고, ReadFile/WriteFile을 하면 어싱크하게 동작한다.
• 이 경우 pdwNumBytes는 의미없으므로 보통 NULL 을 넣는다.
• 또한 OVERLAPPED 구조체를 초기화하여 인자로 제공해야 한다.

The OVERLAPPED Structure

typedef struct _OVERLAPPED { 
    ULONG_PTR  Internal;       // [out] Error code
    ULONG_PTR  InternalHigh; // [out] Numver of bytes transferred
    DWORD  Offset;               // [in] Low 32-bit file offset
    DWORD  OffsetHigh;         // [in] High 32-bit file offset
    HANDLE hEvent;              // [in] Event handle or data
} OVERLAPPED; 

#define HasOverlappedIoCompleted(pOverlapped)      ((pOverlapped)->Internal != STATUS_PENDING)

• Offset & OffsetHigh - 64비트 파일 옵셋. 파일이 아닌 디바이스에 대해서도 체크되므로 이 경우는 0 으로 반드시 초기화 해 주어야 한다. 그렇지 않으면 GetLastError()에서 ERROR_INVALID_PARAMETER 가 리턴될 것이다.
• hEvent - I/O completion notification 을 받기 위해 세팅해 준다.
• Internal - 에러코드 혹은 I/O request 처리 상태가 기록된다. 아직 처리시작하지 않은 초기값은 STATUS_PENDING 이다.
• InternalHigh - I/O request가 완료되면 전송된 바이트가 기록된다.

• I/O request가 완료되면 lpOverlapped 의 포인터를 통보받게 된다.
• 만약 더 많은 context 정보 (예를 들어 hFile)를 이 구조체에 넣고 싶다면 방법이 있다. OVERLAPPED를 상속한 구조체를 하나 만들어, lpOverlapped 를 받았을 때 새 구조체로 casting 하면 된다. 즉, 저 포인터는 유지된다.

Asynchronous Device I/O Caveats

• Overlapped I/O 는 FIFO 방식으로 처리되지 않을 수도 있다. 즉, 먼저 요청한 것이 먼저 처리된다고 보장해 주지 않는다.
• 에러처리에 주의할 것:
  • async 로 요청해도 sync 로 처리될 수가 있다. (캐쉬에 있는 경우 등) 이런 경우에는 TRUE 가 리턴되므로 따로 처리할 것.
  • 에러가 나거나 request 가 queue 에 들어가면 FALSE 가 리턴된다.
    • GetLastError()를 해봐야 한다.
    • ERROR_IO_PENDING 이면 성공적으로 큐잉된 것.
    • 다른 값이면 에러 발생.
    • ERROR_INVALID_USER_BUFFER or ERROR_NOT_ENOUGH_MEMORY : device 의 사용자 버퍼가 꽉 찬 경우
    • ERROR_NOT_ENOUGH_QUOTA : device 에 따라 buffer (memory)를 page lock 해야 하는 경우가 있다. 싱글 프로세스가 할 수 있는 page lock의 사이즈는 미리 정해져 있으므로 이를 넘기면 page lock 에 실패하게 된다. 이때 발생하는 에러. SetProcessWorkingSetSize() 로 이 양을 늘릴 수 있다.
  • 에러 해결법: 이 에러들은 결국 너무 많은 I/O request가 처리되지 못한 채 남아 있기에 생기는 것이다. 그러므로 잠시 요청을 보류했다가 다시 ReadFile이나 WriteFile을 호출하면 될 것이다.
• Data Buffer와 OVERLAPPED 구조체의 메모리는 I/O request가 완료될 때까지 해제되거나 이동되어서는 안된다!! 물론 각 I/O request에 대해 OVERLAPPED 구조체는 모두 달라야 한다!!

Cancelling Queued I/O Requests

• BOOL CancelIo( HANDLE hFile )
• handle 을 닫으면 모든 큐잉된 i/o는 취소된다.
• 스레드가 죽으면 그 스레드가 큐잉한 i/o는 자동으로 취소된다.
• 특정 i/o request 하나만을 취소하는 방법은 없다.
• 취소된 I/O request는 ERROR_OPERATION_ABORTED 값을 가지고 complete 처리된다.

Receiving Completed I/O Request Notifications

• I/O request가 완료되었을 때 notification 을 받는 방법은 4 가지가 있다.

Method 1. Signaling a Device Kernel Object

• thread syncronization : 결국 device 에의 요청이 처리되었는지를 기다려야 한다.
• 커널 오브젝트는 signaled state나 nonsignaled state 중의 한 값을 가지게 된다.
• WaitForSingleObject() 나 WaitForMultipleObjects() 를 써서 request 가 완료되었는지 알 수 있다.

Method 2. Signaling an Event kernel Object

• OVERLAPPED 구조체의 hEvent 파라메터를 이용한다.
• hEvent 의 이벤트 핸들은 CreateEvent()를 이용해서 생성.
• multiple object의 대기는 WaitForMultipleObjects()를 이용해서 할 수 있다.
• 물론, WaitForSingleObject()로 하나씩 기다려도 된다.
• GetOverlappedResult()

BOOL GetOverlappedResult(
  HANDLE hFile,                       // handle to file, pipe, or device
  LPOVERLAPPED lpOverlapped,          // overlapped structure
  LPDWORD lpNumberOfBytesTransferred, // bytes transferred
  BOOL bWait                          // wait option
);

Method 3. Alertable I/O

• 이 넘은 지저분 하므로 가능하면 피해야 한다. 하지만 OS에 포함된 그 지원부분은 쓸법한 것이 있다.
• APC Queue: an Asynchronous Procedure Call Queue - per threads.
• APC Queue를 이용하려면 ReadFileEx와 WriteFileEx를 써야 한다.

BOOL ReadFileEx(
  HANDLE hFile,                                       // handle to file
  LPVOID lpBuffer,                                    // data buffer
  DWORD nNumberOfBytesToRead,                         // number of bytes to read
  LPOVERLAPPED lpOverlapped,                          // offset
  LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine // completion routine
);

BOOL WriteFileEx(
  HANDLE hFile,                                       // handle to output file
  LPCVOID lpBuffer,                                   // data buffer
  DWORD nNumberOfBytesToWrite,                        // number of bytes to write
  LPOVERLAPPED lpOverlapped,                          // overlapped buffer
  LPOVERLAPPED_COMPLETION_ROUTINE lpCompletionRoutine // completion routine
);

VOID CALLBACK FileIOCompletionRoutine(
  DWORD dwErrorCode,                // completion code
  DWORD dwNumberOfBytesTransfered,  // number of bytes transferred
  LPOVERLAPPED lpOverlapped         // I/O information buffer
);

• ReadFileEx/WriteFileEx에 callback 함수를 지정하여 호출한다. (무조건 async i/o request)
• tip: 이 경우 OVERLAPPED::hEvent 는 전혀 사용되지 않으므로, 원하는 용도로 써도 된다.
• i/o request가 처리되면 device driver는 그 정보를 APC Queue에 등록한다. APC Queue에는 callback function의 주소와 처리결과를 저장한 entry 들이 있는데, 실제로 callback 이 호출되는 것은 이후의 시점이다. 그 시점이란 바로 thread가 alertable 상태가 되는 것이다.
• thread를 altertable 상태로 만드는 함수는 5 개가 있다.
  • DWORD SleepEx( DWORD dwTimeout, BOOL fAlertable )
  • DWORD WaitForSingleObjectEx( HANDLE hObject, DWORD dwTimeout, BOOL fAlertable )
  • DWODD WaitForMultipleObjectsEx( DWOD cObjects, PHANDLE phObjects, BOOL fWaitAll, DWORD dwTimeout, BOOL fAlertable )
  • BOOL SingleObjectAndWait( HANDLE hObjectToSignal, HANDLE hObjectToWaitOn, DWORD dwMilliseconds, BOOL fAlertable )
  • DWORD MsgWaitForMultipleObjectsEx( DWORD nCount, PHANDLE pHandles, DWORD dwMilliseconds, DWORD dwWakeMask, DWORD dwFlags )
• 위의 함수들은 thread 가 alertabe 상태가 되어 하나라도 i/o complete 를 확인하고 callback function 을 호출했으면 WAIT_IO_COMPLETION 을 리턴. 그렇지 않으면 sleep 했다가 timeout 되어 일어날 것임.

• DWORD QueueUserAPC( PAPCFUNC pfnAPC, HANDLE hThread, ULONG_PTR dwData )
  • pfnAPC : VOID WINAPI APCFunc( ULONG_PTR dwParam )
  • hThread : 다른 프로세스의 thread 도 가능. 이 경우에도 pfnAPC는 해당 스레드의 주소공간이어야 함.
  • dwData : 그저 callback 함수에 넘겨지는 값. 이를 통해 다른 프로세스/스레드와 간단한 통신을 할 수 있다.
  • 이 함수는 wait state 의 thread를 강제로 깨어나게 할 수 있다. (Graceful Close: 깨긋한 쓰레드 죽이기 구현 등에 사용가능)

Method 4. I/O Completion Ports

• Serial model: ping 서버처럼 클라이언트의 요구를 짧게 처리할 수 있는 일.
• Concurrent model: listening thread와 working thread가 분리된 모델. context switching 비용이 너무 많이 든다.

Creating an I/O Completion Port

• I/O completion port는 thread pool 모델에서 사용되도록 만들어 졌다.

HANDLE CreateIoCompletionPort (
  HANDLE FileHandle,              // handle to file
  HANDLE ExistingCompletionPort,  // handle to I/O completion port
  ULONG_PTR CompletionKey,        // completion key
  DWORD NumberOfConcurrentThreads // number of threads to execute concurrently
);

• 이 함수는 매우 복잡하고 두 부분을 포괄하고 있으므로 다음의 두 가지 작은 함수로 분할할 것을 제안한다.
• 첫번째 부분: i/o completion port 생성.

HANDLE CreatenewCompletionPort( DWORD dwNumberOfConcurrentThreads ) {
  return (CreateIoCompletionPort( INVALID_HANDLE_VALUE, NULL, 0, dwNumberOfConcurrentThreads ));

• i/o completion port의 생성은 다음의 5 가지 구조의 생성을 야기한다.
  • Device List
  • I/O Completion Queue (FIFO)
  • Waiting Thread Queue (LIFO)
  • Released Thread List
  • Paused Thread List

Associating a Device with an I/O Completion Port

• 두번째 부분: device와 completion port를 연결

BOOL AssociateDeviceWithCompletionPort( HANDLE hCompPort, HANDLE hDevice, DWORD dwCompKey ) {
  HANDLE h = CreateIoCompletionPort( hDevice, hCompPort, dwCompKey, 0 );
  return ( h == hCompPort );
}

Archtecting Around an I/O Completion Port

• thread pool 은 kernel 에 의해 관리되는 모양(?)
• concurrent 하게 실행되는 스레드의 수는 CPU의 개수와 같게. 실제로 생성하는 스레드의 개수는 CPU 개수 x 2 가 권장사항.

• 각 스레드는 루프를 돌며 device I/O 가 끝나기를 기다리곤 할 것이다. (thread sleep!)
• 이 작업을 하는 것이 GetQueuedCompletionStatus() 함수.

BOOL GetQueuedCompletionStatus(
  HANDLE CompletionPort,       // handle to completion port
  LPDWORD lpNumberOfBytes,     // bytes transferred
  PULONG_PTR lpCompletionKey,  // file completion key
  LPOVERLAPPED *lpOverlapped,  // buffer
  DWORD dwMilliseconds         // optional timeout value
);

• 이 thread는 커널 내부의 waiting thread queue에 등록됨.
• i/o completion 이 일어나면 커널이 해당 thread를 깨움.
• GetQueuedCompletionStatus()의 리턴값을 결정하는 것은 조금 복잡하다. (샘플코드를 볼것)
• Waiting Thread Queue가 LIFO인 것은 성능 향상을 위한 것. i/o completion의 속도가 느리다면 적은 수 (혹은 1개)의 스레드만 쓰일 것이고, 나머지는 디스크에 flush 되거나 하여 리소스를 거의 쓰지 않게된다.

How the I/O Completion Port Manages the Thread Pool

1. I/O completion 을 만들면서 concurrent thread의 개수는 CPU의 개수로 세팅.
2. 실제 스레드는 CPU개수x2 개를 생성
3. completed I/O가 큐에 들어오면 completion port가 waiting thread를 하나 깨워서 released thread queue로 옮김.
4. 만약 running thread가 Sleep(), WaitForSingleObject()등의 sleep을 유도하는 함수를 call하면, paused thread queue로 옮겨감. 이때, released queue의 수가 감소하므로 completion port가 waiting thread의 다른 스레드를 깨워 completed I/O를 처리하도록 함. (최대 CPU의 개수!)
5. 중간에 paused thread가 특정 조건을 만족하면서 다시 깨어남. completion port는 이를 감지하고 이 스레드를 released thread queue로 옮김. 이 때 순간적으로 지정했던 concurrency thread의 개수보다 많은 스레드가 실행됨.
6. 보통 루프를 돌면서 다시 GetQueuedCompletionStatus()를 호출하게 되므로 이 스레드 들은 waiting thread queue로 돌아감.

• 이런 식으로 released thread queue는 항상 최대 개수로 유지되며, context switching의 회수가 최소로 유지되는 가운데, 최대 효율로 돌아가게 됨.

How Many Threads in the Pool?

• heuristic algorithms (가이드라인 샘플 코드 참조)

Simulating Completed I/O Requests

• PostQueuedCompletionStatus 를 이용해서 가짜 i/o completion entry를 올릴 수 있다.
• 이를 이용해서 thread 간의 통신을 할 수 있다!
• thread의 graceful close 를 할 수 있으나, 이 경우 wait thread queue가 LIFO 라는 것을 주의해야 한다. (책잠조)

BOOL PostQueuedCompletionStatus(
  HANDLE CompletionPort,            // handle to an I/O completion port
  DWORD dwNumberOfBytesTransferred, // bytes transferred
  ULONG_PTR dwCompletionKey,        // completion key 
  LPOVERLAPPED lpOverlapped         // overlapped buffer
);

Tips From This Book