[
https://issues.apache.org/jira/browse/TS-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12829797#action_12829797
]
Sean Cosgrave commented on TS-116:
----------------------------------
Your suggestion in 2) would not create the same logic as I currently have. My
current logic says that if the setup is wrong, and max < min, then don't try
and keep a minimum number of connections alive. You suggest I set them to be
equal, and don't make the comparison in HttpSessionManager. Setting them equal
would mean we would always try and keep the connections alive because we could
never get above the min, since it is also the max. I'm not sure that is the
behavior we are looking for. I guess it might provide a performance improvement
since we would then take advantage of the feature in those cases where max <
min originally. The other side effect of the change would be that we would go
above the maximum number of connections to an origin set in the config. I think
those are both acceptable side effects.
> 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.
