Apache 2.4 - Tomcat Connectors 1.2.48 - workers.properties
필요한 내용은 계속 업데이트 할 예정입니다.
The Apache Tomcat Connectors - Reference Guide (1.2.48) - workers.properties configuration
The Apache Tomcat Connectors - Reference Guide (1.2.48) - workers.properties configuration
This table lists more advanced configuration options. Most of them only apply to some types of workers. We use the abbreviations AJP for ajp13/ajp14 workers used directly via the workers.list, LB for load balancer workers, and SUB for the workers used indi
tomcat.apache.org
method
Specifies what method load balancer is using for electing the best worker. Please note, that session stickiness and perfect load balancing are conflicting targets, especially when the number of sessions is small, or the usage of sessions is extremely varying For huge numbers of sessions this usually is not a problem.
로드 밸런서가 가장 좋은 워커(worker)를 선출하는 데 사용하는 방법을 지정합니다. 세션 스티키(session stickiness)와 완벽한 로드 밸런싱(load balancing)은 특히 세션이 적거나 세션 사용이 극도로 다양한 경우 상충하는 목표입니다. 매우 많은 세션의 경우에는 일반적으로 문제가 발생하지 않습니다.
Some methods note, that they aggregate in a sliding time window. They add up accesses, and on each run of the global maintain method, the load counters get divided by 2. Usually this happens once a minute, depending on the setting of worker.maintain. The value of the load counters can be inspected using the status worker.
일부 방법은 슬라이딩 시간 창에서 집계한다는 것을 알려줍니다. 접근 횟수(accesses)를 더하고 전역 유지 관리 메서드(global maintain method)를 실행할 때마다 로드 카운터(load counters)가 2로 나누어집니다. 일반적으로 이는 worker.maintain 설정에 따라 1분에 한 번 발생합니다. 로드 카운터의 값은 상태(worker) 작업자를 통해 검사할 수 있습니다.
If method is set to R[equest] the balancer will use the number of requests to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This is the default value and should be working well for most applications.
방법(method)이 R[equest]로 설정되면 로드 밸런서는 가장 좋은 워커를 찾기 위해 요청(requests) 수를 사용합니다. 접근(accesses)은 슬라이딩 시간 창에서 lbfactor에 따라 분산됩니다. 이것은 기본값이며 대부분의 응용 프로그램에 대해 잘 작동해야합니다.
If method is set to S[ession] the balancer will use the number of sessions to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if sessions are your limiting resource, e.g. when you only have limited memory and your sessions need a lot of memory. Because the balancer does not keep any state, it actually does not know the number of sessions. Instead it counts each request without a session cookie or URL encoding as a new session. This method will neither know, when a session is being invalidated, nor will it correct its load numbers according to session timeouts or worker failover. If you know request URLs, that will be called without a session ID but should not be counted as new sessions, you should add them to the stateless mapping rule extension or set the Apache HTTP Server environment variable JK_STATELESS for them.
방법(method)이 S[ession]로 설정되면 로드 밸런서는 세션(session) 수를 사용하여 가장 좋은 워커를 찾습니다. 접근(accesses)은 슬라이딩 시간 창에서 lbfactor에 따라 분산됩니다. 이 방법은 세션이 제한적인 리소스인 경우, 예를 들어 제한된 메모리만 사용 가능하고 세션이 많은 메모리를 필요로 할 때 사용해야합니다. 로드 밸런서는 상태를 유지하지 않기 때문에 실제로 세션 수를 알지 못합니다. 대신 세션 쿠키나 URL 인코딩이 없는 각 요청을 새 세션으로 계산합니다. 이 방법은 세션이 무효화되었을 때도 알 수 없으며 세션 만료 또는 워커 장애 조치에 따라 로드 번호를 수정하지 않습니다. 세션 ID가없는 호출해야하는 요청 URL을 알고 있다면 상태 없는 매핑 규칙 확장(extension)에 추가하거나 해당 요청에 대해 Apache HTTP Server 환경 변수 JK_STATELESS를 설정해야합니다.
If method is set to N[ext] the balancer will again use the number of sessions to find the best worker. All remarks concerning the Sessionmethod apply as well. The difference to the Session method is how the session count is handled in the sliding time window. The Next method does not divide by 2, instead it subtracts the current minimum number. This should effectively result in a round-robin session balancing, thus the name Next. Under high load, the two session balancing methods will result in a similar distribution, but Next will be better if you need to distribute small numbers of sessions.
만약 method가 N[ext]로 설정되어 있다면, 로드 밸런서는 다시 한 번 최적의 워커를 선택하기 위해 세션 수를 사용합니다. Session method에 대한 모든 의견이 적용됩니다. 다음 방법은 슬라이딩 시간 창에서 세션 수를 처리하는 방법과 차이가 있습니다. Next 방법은 현재 최소값을 뺍니다. 이렇게하면 라운드 로빈 세션 밸런싱이 효과적으로 이루어지며, 이에 따라 Next라는 이름이 붙게됩니다. 높은 부하 하에서는 두 세션 밸런싱 방법이 유사한 분포를 보이지만, 작은 수의 세션을 분배해야하는 경우 Next가 더 나은 선택입니다.
If set to T[raffic] the balancer will use the network traffic between JK and Tomcat to find the best worker. Accesses will be distributed according to the lbfactor in a sliding time window. This method should be used, if network to and from the backends is your limiting resource.
만약 T[raffic]로 설정된 경우, 로드 밸런서는 JK와 Tomcat 간의 네트워크 트래픽을 사용하여 최적의 워커를 선택합니다. 접근은 슬라이딩 시간 창에서 lbfactor에 따라 분배됩니다. 이 방법은 백엔드로부터의 네트워크 제한 자원인 경우에 사용해야합니다.
If set to B[usyness] the balancer will pick the worker with the lowest current load, based on how many requests the worker is currently serving. This number is divided by the workers lbfactor, and the lowest value (least busy) worker is picked. This method is especially interesting, if your request take a long time to process, like for a download application. The method is not recommended for general use, because under high load on some hardware architectures the busy counter can become wrong.
만약 B[usyness]로 설정된 경우, 로드 밸런서는 현재 서비스 중인 요청 수에 따라 가장 낮은 현재 로드를 가진 워커를 선택합니다. 이 수는 워커의 lbfactor로 나누어지며, 가장 작은 값을 (가장 적게 바쁜) 워커가 선택합니다. 이 방법은 다운로드 애플리케이션과 같이 요청 처리 시간이 긴 경우 특히 흥미롭습니다. 그러나 하드웨어 아키텍처에 따라 바쁜 카운터가 잘못되는 경우가 있으므로 일반적으로 권장되지 않습니다.
This feature has been added in version 1.2.9. The Session method has been added in version 1.2.20, the Next method in version 1.2.33.
이 기능은 버전 1.2.9에서 추가되었습니다. 세션 방법은 버전 1.2.20에서 추가되었으며, Next 방법은 버전 1.2.33에서 추가되었습니다.