일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 26 | 27 | 28 | 29 | 30 |
- notification manager
- setDefaults(NotificationCompat.DEFAULT_ALL)
- notification channel
- 알림 우선순위
- 안드로이드 알림
- NotificationCompat.Builder
- 안드로이드 알림채널
- 안드로이드 알림 예제
- notifications
- 펜딩인텐트
- android notification 예제
- setPriority(NotificationCompat.PRIORITY_HIGH)
- 알림 인텐트
- setContentIntent
- 버전별 관리
- Pending Intent
- Today
- Total
공부용 블로그
Apache 마인드맵 본문
1. Apache의 MPM(Multi Process Module) 방식이란?
The Apache HTTP Server is designed to be a powerful and flexible web server that can work on a very wide variety of platforms in a range of different environments. Different platforms and different environments often require different features, or may have different ways of implementing the same feature most efficiently. Apache has always accommodated a wide variety of environments through its modular design. This design allows the webmaster to choose which features will be included in the server by selecting which modules to load either at compile-time or at run-time.
Apache http 서버는 다양한 플랫폼에서 사용할 수 있도록 디자인되었다.
다른 플랫폼, 다른 환경은 종종 다른 특징들을 요구한다. 또한 동일한 기능을 가장 효율적으로 구현하는 방법이 다를 수 있다.
이 디자인은 서버안에서 컴파일 타임 혹은 런타임 중 어떤 모듈로 로드할지 선택할 수 있게 한다.
2. prefork, worker, event 방식의 차이점과 특징은?
(1) Prefork MPM
Summary
This Multi-Processing Module (MPM) implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3. It is appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries. It is also the best MPM for isolating each request, so that a problem with a single request will not affect any other.
This MPM is very self-regulating, so it is rarely necessary to adjust its configuration directives. Most important is that MaxClients
be big enough to handle as many simultaneous requests as you expect to receive, but small enough to assure that there is enough physical RAM for all processes.
논스레드 방식.
스레드로부터 안전하지 않은 라이브러리와의 호환성을 위해 스레딩을 피할 필요가 있는 사이트에 적합하다.
또한 각 요청의 독립성을 보장하기 때문에 하나의 요청이 다른 것에 영향을 주지 않는다.
중요한 점은 MaxClients가 당신이 받을거라고 예상하는 동시요청수를 다룰 수 있을 만큼 충분하면서도
모든 프로세스를 위한 물리적 RAM에서 수용할만큼 충분히 작아야한다(내 해석이므로 명확하지않음. 추측).
Parent Process는 시작시 Child Process 풀을 미리 포크(StartServers 수 만큼 생성)하는데 사용된다.
각 idle child process는 들어오는 요청을 수신하기 위해 큐에 조인한다.
이 MPM은 오직 하나의 프로세스가 수신하고 다음 TCP 요청을 받아들이는 것을 보장하기 위해
accept mutex 메서드를 사용한다.
* Mutex (Mutual exclusion. 상호배제)
'임계 영역'이라고도 한다. 서로 다른 두 프로세스 혹은 스레드 등의 처리 단위가 같이 접근해서는 안 되는 공유 영역을 뜻한다.
(2) Worker MPM
Parent process는 StartServers 에서 정해진 수 만큼 child process를 생성한다.
각 child process는 Listener Thread와 함께 ThreadsPerChild 만큼의 스레드를 만든다.
Prefork와 마찬가지로 Worker MPM은 다음 들어오는 요청을 처리할 스레드를 지정하기 위해 mutex를 허용한다.
child process내에 적어도 하나의 idle thread가 존재한다면 각 child process의 listener thread는 유휴 큐만 조인한다.
뮤텍스를 갖고 있는 리스너 스레드는 요청이 들어오면 연결을 수락하고 뮤텍스를 다른 리스너 스레드에게 넘겨주고
현재 유휴 스레드에게 작업을 요청한다.
유휴 스레드는 새로운 요청을 위해 기다리고 있으므로 새로운 스레드를 만드는 시간을 낭비할 필요가 없다.
(그럼 요청 수가 많아져서 모든 스레드가 일하고 있는 경우, 최대 스레드 설정 수(ThredsPerChild)까지 초과했다면
일하고 있는 스레드가 일을 마칠때까지 기다렸다가 순차적으로 처리할까 혹은 새로운 스레드를 생성할까?)
worker thread를 사용하면 여러 스레드를 활용하여 각 child process가 한 번의 둘 이상의 요청을 처리할 수 있다.
연결당 하나의 스레드만 필요하기 때문에 연결당 하나의 프로세스를 필요로 하는 profork방식보다 메모리 효율이 높다.
(3) Event MPM
Worker 방식과 마찬가지로 Parent Process는 각 하위에 child process들을 생성(StartServers 수 만큼)하고
각 child process는 listener thread와 함께 여러개의 스레드(ThreadsPerChild 수 만큼)를 생성한다.
'설계 > WebServer' 카테고리의 다른 글
Jetty 설치 (0) | 2018.10.27 |
---|---|
ubuntu 16.04 $JAVA_HOME 설정 (0) | 2018.10.25 |
JAVA NIO 와 Selector (0) | 2018.10.19 |
비동기처리, 콜백 함수 (0) | 2018.10.19 |
vert.x 구조 이해하기 (0) | 2018.10.18 |