server-side/haproxy
HAProxy Gateway timeout
C/H
2017. 6. 15. 08:30
jquery.min.js:4 GET https://domain.com/v1/dashboard/month_report/format/json/?callback=callback&date=2017-06 504 (Gateway Time-out)
Configuration
keyword defaults frontend listen backend ------------------------------------+----------+----------+---------+--------- srvtimeout (deprecated) X - X X timeout srvtimeout (deprecated) X - X X timeout server X - X X clitimeout (deprecated) X X X - timeout clitimeout (deprecated) X X X - timeout client X X X -
srvtimeout timeout server
srvtimeout <timeout> (deprecated) Set the maximum inactivity time on the server side. 서버 측 최대 비 활동 시간. May be used in sections : defaults | frontend | listen | backend yes | no | yes | yes Arguments : <timeout> is the timeout value specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as explained at the top of this document. 기본 밀리 초 단위로 지정된 제한 시간 값이지만이 문서의 맨 위에 설명 된대로 장치의 숫자 뒤에 다른 단위가있을 수 있습니다. The inactivity timeout applies when the server is expected to acknowledge or send data. 비활성 시간 초과는 서버가 데이터를 수신 확인하거나 보낼 것으로 예상 될 때 적용됩니다. In HTTP mode, this timeout is particularly important to consider during the first phase of the server's response, when it has to send the headers, as it directly represents the server's processing time for the request. HTTP 모드에서이 시간 초과는 요청의 서버 처리 시간을 직접 나타 내기 때문에 헤더를 보내는 서버 응답의 첫 단계에서 고려해야 할 특히 중요합니다. To find out what value to put there, it's often good to start with what would be considered as unacceptable response times, then check the logs to observe the response time distribution, and adjust the value accordingly. 어떤 값을 넣을 지 알아 내려면 받아 들일 수없는 응답 시간으로 간주되는 것으로 시작한 다음 로그를 확인하여 응답 시간 분포를 관찰하고 이에 따라 값을 조정하는 것이 좋습니다. The value is specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as specified at the top of this document. 값은 기본적으로 밀리 초 단위로 지정되지만이 문서의 맨 위에 명시된대로 장치의 접미사가 다른 단위 일 수 있습니다. In TCP mode (and to a lesser extent, in HTTP mode), it is highly recommended that the client timeout remains equal to the server timeout in order to avoid complex situations to debug. Whatever the expected server response times, it is a good practice to cover at least one or several TCP packet losses by specifying timeouts that are slightly above multiples of 3 seconds (eg: 4 or 5 seconds minimum). TCP 모드에서 (그리고 HTTP 모드에서는 다소 적지 만) 복잡한 상황이 디버깅되지 않도록 클라이언트 시간 초과를 서버 시간 초과와 동일하게 유지하는 것이 좋습니다. 예상되는 서버 응답 시간에 관계없이 3 초의 배수 (예 : 4 초 또는 5 초)보다 약간 긴 시간 초과를 지정하여 하나 이상의 TCP 패킷 손실을 처리하는 것이 좋습니다. This parameter is specific to backends, but can be specified once for all in "defaults" sections. 이 매개 변수는 백엔드에만 적용되지만 "defaults"섹션의 모든 항목에 대해 한 번 지정할 수 있습니다. This is in fact one of the easiest solutions not to forget about it. 이것은 사실 잊지 않는 가장 쉬운 해결책 중 하나입니다. An unspecified timeout results in an infinite timeout, which is not recommended. 지정되지 않은 시간 초과로 인해 무제한 시간 초과가 발생하며 이는 권장되지 않습니다. Such a usage is accepted and works but reports a warning during startup because it may results in accumulation of expired sessions in the system if the system's timeouts are not configured either. 이러한 사용은 허용되고 작동하지만 시스템의 시간 초과가 구성되지 않은 경우 시스템에 만료 된 세션이 누적 될 수 있으므로 시작 중에 경고를보고합니다. This parameter is provided for compatibility but is currently deprecated. 이 매개 변수는 호환성을 위해 제공되었지만 현재 사용되지 않습니다. Please use "timeout server" instead. 대신 "timeout server"를 사용하십시오. See also : "timeout server", "timeout tunnel", "timeout client" and "clitimeout".
timeout server
timeout server <timeout> timeout srvtimeout <timeout> (deprecated) Set the maximum inactivity time on the server side. 서버 측 최대 비 활동 시간을 설정 May be used in sections : defaults | frontend | listen | backend yes | no | yes | yes Arguments : <timeout> is the timeout value specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as explained at the top of this document. 기본 밀리 초 단위로 지정된 제한 시간 값이지만이 문서의 맨 위에 설명 된대로 장치의 숫자 뒤에 다른 단위가있을 수 있습니다. The inactivity timeout applies when the server is expected to acknowledge or send data. In HTTP mode, this timeout is particularly important to consider during the first phase of the server's response, when it has to send the headers, as it directly represents the server's processing time for the request. 비활성 시간 초과는 서버가 데이터를 수신 확인하거나 보낼 것으로 예상 될 때 적용됩니다. HTTP 모드에서이 시간 초과는 요청의 서버 처리 시간을 직접 나타 내기 때문에 헤더를 보내는 서버 응답의 첫 단계에서 고려해야 할 특히 중요합니다. To find out what value to put there, it's often good to start with what would be considered as unacceptable response times, then check the logs to observe the response time distribution, and adjust the value accordingly. 어떤 값을 넣을 지 알아 내려면 받아 들일 수없는 응답 시간으로 간주되는 것으로 시작한 다음 로그를 확인하여 응답 시간 분포를 관찰하고 이에 따라 값을 조정하는 것이 좋습니다. The value is specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as specified at the top of this document. 값은 기본적으로 밀리 초 단위로 지정되지만이 문서의 맨 위에 명시된대로 장치의 접미사가 다른 단위 일 수 있습니다. In TCP mode (and to a lesser extent, in HTTP mode), it is highly recommended that the client timeout remains equal to the server timeout in order to avoid complex situations to debug. Whatever the expected server response times, it is a good practice to cover at least one or several TCP packet losses by specifying timeouts that are slightly above multiples of 3 seconds (eg: 4 or 5 seconds minimum). If some long-lived sessions are mixed with short-lived sessions (eg: WebSocket and HTTP), it's worth considering "timeout tunnel", which overrides "timeout client" and "timeout server" for tunnels. TCP 모드에서 (그리고 HTTP 모드에서는 다소 적지 만) 복잡한 상황이 디버깅되지 않도록 클라이언트 시간 초과를 서버 시간 초과와 동일하게 유지하는 것이 좋습니다. 예상되는 서버 응답 시간에 관계없이 3 초의 배수 (예 : 4 초 또는 5 초)보다 약간 긴 시간 초과를 지정하여 하나 이상의 TCP 패킷 손실을 처리하는 것이 좋습니다. 일부 오래 지속되는 세션이 단명 세션 (예 : WebSocket 및 HTTP)과 섞여 있다면 "시간 초과 클라이언트"및 터널의 "시간 초과 서버"를 무시하는 "시간 초과 터널"을 고려해 볼 가치가 있습니다. This parameter is specific to backends, but can be specified once for all in "defaults" sections. 이 매개 변수는 백엔드에만 적용되지만 "defaults"섹션의 모든 항목에 대해 한 번 지정할 수 있습니다. This is in fact one of the easiest solutions not to forget about it. An unspecified timeout results in an infinite timeout, which is not recommended. 이것은 사실 잊지 않는 가장 쉬운 해결책 중 하나입니다. 지정되지 않은 시간 초과로 인해 무제한 시간 초과가 발생하며 이는 권장되지 않습니다. Such a usage is accepted and works but reports a warning during startup because it may results in accumulation of expired sessions in the system if the system's timeouts are not configured either. 이러한 사용은 허용되고 작동하지만 시스템의 시간 초과가 구성되지 않은 경우 시스템에 만료 된 세션이 누적 될 수 있으므로 시작 중에 경고를보고합니다. This parameter replaces the old, deprecated "srvtimeout". 이 매개 변수는 더 이상 사용되지 않는 "srvtimeout"을 대체합니다. It is recommended to use it to write new configurations. 새 구성을 작성하는 데 사용하는 것이 좋습니다. The form "timeout srvtimeout" is provided only by backwards compatibility but its use is strongly discouraged. "timeout srvtimeout"형식은 이전 버전과의 호환성에서만 제공되지만 그 사용은 강력히 권장되지 않습니다. See also : "srvtimeout", "timeout client" and "timeout tunnel".
clitimeout timeout client
clitimeout <timeout> (deprecated) Set the maximum inactivity time on the client side. 클라이언트 측 최대 비활성 시간을 설정. May be used in sections : defaults | frontend | listen | backend yes | yes | yes | no Arguments : <timeout> is the timeout value is specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as explained at the top of this document. 기본 밀리 초 단위로 지정되는 제한 시간 값이지만이 문서의 맨 위에 설명 된대로 단위가 접미어이면 다른 단위가 될 수 있습니다. The inactivity timeout applies when the client is expected to acknowledge or send data. 비 활동 제한 시간은 클라이언트가 데이터를 수신 확인하거나 보낼 것으로 예상 될 때 적용됩니다. In HTTP mode, this timeout is particularly important to consider during the first phase, when the client sends the request, and during the response while it is reading data sent by the server. HTTP 모드에서이 제한 시간은 클라이언트가 요청을 보내는 첫 번째 단계와 서버에서 보낸 데이터를 읽는 동안 응답하는 동안 고려해야 할 특히 중요합니다. The value is specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as specified at the top of this document. 값은 기본적으로 밀리 초 단위로 지정되지만이 문서의 맨 위에 명시된대로 장치의 접미사가 다른 단위 일 수 있습니다. In TCP mode (and to a lesser extent, in HTTP mode), it is highly recommended that the client timeout remains equal to the server timeout in order to avoid complex situations to debug. It is a good practice to cover one or several TCP packet losses by specifying timeouts that are slightly above multiples of 3 seconds (eg: 4 or 5 seconds). TCP 모드에서 (그리고 HTTP 모드에서는 다소 적지 만) 복잡한 상황이 디버깅되지 않도록 클라이언트 시간 초과를 서버 시간 초과와 동일하게 유지하는 것이 좋습니다. 3 초의 배수 (예 : 4 또는 5 초)보다 약간 긴 시간 초과를 지정하여 하나 또는 여러 개의 TCP 패킷 손실을 처리하는 것이 좋습니다. This parameter is specific to frontends, but can be specified once for all in "defaults" sections. This is in fact one of the easiest solutions not to forget about it. 이 매개 변수는 프론트 엔드에 고유하지만 "defaults"섹션의 모든 항목에 대해 한 번 지정할 수 있습니다. 이것은 사실 잊지 않는 가장 쉬운 해결책 중 하나입니다. An unspecified timeout results in an infinite timeout, which is not recommended. 지정되지 않은 시간 초과로 인해 무제한 시간 초과가 발생하며 이는 권장되지 않습니다. Such a usage is accepted and works but reports a warning during startup because it may results in accumulation of expired sessions in the system if the system's timeouts are not configured either. 이러한 사용은 허용되고 작동하지만 시스템의 시간 초과가 구성되지 않은 경우 시스템에 만료 된 세션이 누적 될 수 있으므로 시작 중에 경고를보고합니다. This parameter is provided for compatibility but is currently deprecated. 이 매개 변수는 호환성을 위해 제공되었지만 현재 사용되지 않습니다. Please use "timeout client" instead. 대신 "timeout client"를 사용하십시오. See also : "timeout client", "timeout http-request", "timeout server", and "srvtimeout".
timeout client
timeout client <timeout> timeout clitimeout <timeout> (deprecated) Set the maximum inactivity time on the client side. 클라이언트 측 최대 비활성 시간을 설정 May be used in sections : defaults | frontend | listen | backend yes | yes | yes | no Arguments : <timeout> is the timeout value specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as explained at the top of this document. 기본 밀리 초 단위로 지정된 제한 시간 값이지만이 문서의 맨 위에 설명 된대로 장치의 숫자 뒤에 다른 단위가있을 수 있습니다. The inactivity timeout applies when the client is expected to acknowledge or send data. 비 활동 제한 시간은 클라이언트가 데이터를 수신 확인하거나 보낼 것으로 예상 될 때 적용됩니다. In HTTP mode, this timeout is particularly important to consider during the first phase, when the client sends the request, and during the response while it is reading data sent by the server. HTTP 모드에서이 제한 시간은 클라이언트가 요청을 보내는 첫 번째 단계와 서버에서 보낸 데이터를 읽는 동안 응답하는 동안 고려해야 할 특히 중요합니다. That said, for the first phase, it is preferable to set the "timeout http-request" to better protect HAProxy from Slowloris like attacks. 즉, 첫 번째 단계에서는 Slowloris 공격과 같은 HAProxy를보다 잘 보호 할 수 있도록 "timeout http-request"를 설정하는 것이 좋습니다. The value is specified in milliseconds by default, but can be in any other unit if the number is suffixed by the unit, as specified at the top of this document. 값은 기본적으로 밀리 초 단위로 지정되지만이 문서의 맨 위에 명시된대로 장치의 접미사가 다른 단위 일 수 있습니다. In TCP mode (and to a lesser extent, in HTTP mode), it is highly recommended that the client timeout remains equal to the server timeout in order to avoid complex situations to debug. TCP 모드에서 (그리고 HTTP 모드에서는 다소 적지 만) 복잡한 상황이 디버깅되지 않도록 클라이언트 시간 초과를 서버 시간 초과와 동일하게 유지하는 것이 좋습니다. It is a good practice to cover one or several TCP packet losses by specifying timeouts that are slightly above multiples of 3 seconds (eg: 4 or 5 seconds). 3 초의 배수 (예 : 4 또는 5 초)보다 약간 긴 시간 초과를 지정하여 하나 또는 여러 개의 TCP 패킷 손실을 처리하는 것이 좋습니다. If some long-lived sessions are mixed with short-lived sessions (eg: WebSocket and HTTP), it's worth considering "timeout tunnel", which overrides "timeout client" and "timeout server" for tunnels, as well as "timeout client-fin" for half-closed connections. 일부 수명이 긴 세션이 단명 세션 (예 : WebSocket 및 HTTP)과 섞여 있다면 "timeout client"및 "timeout server"를 무시하는 "timeout tunnel"은 물론 "timeout client-fin" half-closed 연결의 경우. This parameter is specific to frontends, but can be specified once for all in "defaults" sections. 이 매개 변수는 프론트 엔드에 고유하지만 "defaults"섹션의 모든 항목에 대해 한 번 지정할 수 있습니다. This is in fact one of the easiest solutions not to forget about it. An unspecified timeout results in an infinite timeout, which is not recommended. 이것은 사실 잊지 않는 가장 쉬운 해결책 중 하나입니다. 지정되지 않은 시간 초과로 인해 무제한 시간 초과가 발생하며 이는 권장되지 않습니다. Such a usage is accepted and works but reports a warning during startup because it may results in accumulation of expired sessions in the system if the system's timeouts are not configured either. 이러한 사용은 허용되고 작동하지만 시스템의 시간 초과가 구성되지 않은 경우 시스템에 만료 된 세션이 누적 될 수 있으므로 시작 중에 경고를보고합니다. This parameter replaces the old, deprecated "clitimeout". 이 매개 변수는 더 이상 사용되지 않는 "clitimeout"을 대체합니다. It is recommended to use it to write new configurations. 새 구성을 작성하는 데 사용하는 것이 좋습니다. The form "timeout clitimeout" is provided only by backwards compatibility but its use is strongly discouraged. "timeout clitimeout"형식은 이전 버전과의 호환성에서만 제공되지만 그 사용은 강력히 권장되지 않습니다. See also : "clitimeout", "timeout server", "timeout tunnel", "timeout http-request"..
반응형