[jira] Commented: (TS-116) TS should have the ability to keep a minimum number of connections active for all keep alive cases

["Leif Hedstrom (JIRA)" <ji...@apache.org>]

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

Leif Hedstrom commented on TS-116:
----------------------------------

Looks mostly good, couple of small comments:

1) Instead of using HttpConfig::m_master.origin_max_connections, I wonder if you should do something like this:

HttpConfigParams *http_config_params = HttpConfig::acquire();

// Now you can use http_config_params.origin_max_connections  etc. safely.

HttpConfig::release(http_config_params);


2) In HttpSessionManager.cc you have a comparison

HttpConfig::m_master.origin_max_connections > HttpConfig::m_master.origin_min_keep_alive_connections


I'm thinking this should be moved over to where the configuration is parsed, and if the "min" is larger than the "max", produce a warning, and then set 'max' to 'min'. Then you can eliminate that check entirely in the "run-time" code. I noticed in HttpSM.cc you actually do produce warnings in this case.

3) Similar to  2) except in HttpSM you produce a warning when "min" is larger than "max". Why not move this out to config parse time? Otherwise, won't we fill the error logs with this message pretty darn quick?


My recommendation for both 2) and 3) would be to move the logic over to config loading, produce one warning there, and then set "max" to be the same as "min".




> TS should have the ability to keep a minimum number of connections active for all keep alive cases
> --------------------------------------------------------------------------------------------------
>
>                 Key: TS-116
>                 URL: https://issues.apache.org/jira/browse/TS-116
>             Project: Traffic Server
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Sean Cosgrave
>            Assignee: Leif Hedstrom
>             Fix For: 2.0.0a
>
>         Attachments: ka_os_diff.txt
>
>
> Today, TS keeps a keep alive connection to the Origin Server upto the time thats specified in
> proxy.config.http.keep_alive_no_activity_timeout_out in the case that the connection hasnt been re-used for that period
> of time.
> In addition to that, it would be nice to be able to say that if a connection has been opened, keep atleast 'n' number
> of connections open to the OS regardless of the fact that the connection hasnt been used for a while.
> Obviously 'n' has to be a small number so that we dont end up holding up too many connections to the OS unnecessarily,
> since this feature is simply to allow requests that come after that period of time to still enjoy the benefits of YCPI
> reducing the impact of TCP's 3-way HandShake (especially over a long distance).
> Also, do note, that a connection close event from the Origin Server should obviously be handled correctly and the
> connection should be removed from the pool. In that case, no new connections have to be re-opened to maintain 'n'. This
> can purely be done on demand.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.