[jira] [Comment Edited] (TS-2107) add absolute proxy.config.http.transaction_active_timeout_in about request

["Zhao Yongming (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/TS-2107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13741838#comment-13741838 ] 

Zhao Yongming edited comment on TS-2107 at 8/16/13 2:57 AM:
------------------------------------------------------------

the transaction active timeout in is total time a client request can live on, where mostly we do not try to control there, instead we can try to limit the request time, and the request is able to split into request header & request body (the whole request), the request header is mostly like to be 4KB in normal request, although it may be <64KB, and because it is the earliest of a client request, it is the most useful control point of the client transaction active timeout.

IMO, a common setting for a client transaction active timeout:
{code}
  proxy.config.http.transaction_header_timeout_in=5s
  proxy.config.http.transaction_request_timeout_in=10s
{code}
if the client request is too slow to finish that header sending in 5s, we'd better abandon it.

if you working on POST requests, you may try to limit the request timeout to 10m or set it 0 to disable the timeout:
{code}
  proxy.config.http.transaction_request_timeout_in=600
{code}
compare to the nginx:
there is some similar setting for example: http://wiki.nginx.org/HttpCoreModule#client_header_timeout

then, we can really fill some numbers in proxy.process.http.408_responses

as of the complex we introduced here, maybe we can remove the ransaction_active_timeout_in, for a trade off.

your comments?
                
      was (Author: zym):
    the transaction active timeout in is total time a client request can live on, where mostly we do not try to control there, instead we can try to limit the request time, and the request is able to split into request header & request body (the whole request), the request header is mostly like to be 4KB in normal request, although it may be <64KB, and because it is the earliest of a client request, it is the most useful control point of the client transaction active timeout.

IMO, a common setting for a client transaction active timeout:
  proxy.config.http.transaction_header_timeout_in=5s
  proxy.config.http.transaction_request_timeout_in=10s
if the client request is too slow to finish that header sending in 5s, we'd better abandon it.

if you working on POST requests, you may try to limit the request timeout to 10m or set it 0 to disable the timeout:
  proxy.config.http.transaction_request_timeout_in=600

compare to the nginx:
there is some similar setting for example: http://wiki.nginx.org/HttpCoreModule#client_header_timeout

then, we can really fill some numbers in proxy.process.http.408_responses

as of the complex we introduced here, maybe we can remove the ransaction_active_timeout_in, for a trade off.

your comments?
                  
> add absolute proxy.config.http.transaction_active_timeout_in  about request
> ---------------------------------------------------------------------------
>
>                 Key: TS-2107
>                 URL: https://issues.apache.org/jira/browse/TS-2107
>             Project: Traffic Server
>          Issue Type: New Feature
>          Components: HTTP
>    Affects Versions: 3.3.5
>            Reporter: Bin Chen
>            Assignee: Bin Chen
>             Fix For: 3.5.1
>
>
> Now, ts use proxy.config.http.transaction_active_timeout_in handle request and response transaction. But in some very bad network, we catch some log that it cost >30s to get ua_read_header_done, that is unacceptable, should be controled with some dedicated timeout in records.config.
> we world prefer to add proxy.config.http.transaction_header_timeout_in proxy.config.http.transaction_request_timeout_in
> {code}
> [Aug  6 22:11:46.698] Server {0x2b37cf0f9700} ERROR: [1366077161] Slow Request: url: http://xxxxx/853771125_1448036722.jpg status: 0 unique id:  bytes: 0 fd: 0 client state: 0 server state: 0 ua_begin: 0.000 ua_read_header_done: 46.790 cache_open_read_begin: 46.790 cache_open_read_end: -1.000 dns_lookup_begin: -1.000 dns_lookup_end: -1.000 server_connect: -1.000 server_first_read: -1.000 server_read_header_done: -1.000 server_close: -1.000 ua_close: 46.790 sm_finish: 46.790
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira