[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13922316#comment-13922316
]
Leif Hedstrom edited comment on TS-153 at 3/6/14 11:07 AM:
-----------------------------------------------------------
I spoke with John about this before, and he seemed favorable to these ideas. I
really think we should generalize this, such that we move VCs between LRUs
instead of inactivity / timeout events.
>From a configuration perspective, what the user generally keeps about is to
>not run out of file descriptors; In a sense, you configure your system based
>on a fixed set of resources, and trying to guess timeout values is virtually
>impossible.
There's still room for timeouts, such that you also enforce certain max
lifetimes in each of the LRUs. But this would be easily to clean out, walking
the LRUs periodically (once a second?) starting from the bottom. Since the LRUs
are by definition ordered, this is very efficient; You only traverse entries
that would be evicted, and nothing else.
I know I'm repeating myself here, but I'm hugely positive to these changes, and
I think this can enable us to handle a large number of VCs with little overhead
and significantly easier management.
was (Author: zwoop):
I spoke with John about this before, and he seemed favorable to these ideas. I
really think we should generalize this, such that we move VCs between LRUs
instead of inactivity / timeout events.
>From a configuration perspective, what the user generally keeps about is to
>not run out of file descriptors; In a sense, you configure your system based
>on a fixed set of resources, and trying to guess timeout values is virtually
>impossible.
There's still room for timeouts, such that you also enforce certain max
lifetimes in each of the LRUs. But this would be easily to clean out, walking
the LRUs periodically (once a second?) starting from the bottom. Since the LRUs
are by definition ordered, this is very efficient; You only traverse entries
that would be evicted, and nothing else.
> "Dynamic" keep-alive timeouts
> -----------------------------
>
> Key: TS-153
> URL: https://issues.apache.org/jira/browse/TS-153
> Project: Traffic Server
> Issue Type: New Feature
> Components: Core
> Reporter: Leif Hedstrom
> Assignee: Bryan Call
> Priority: Minor
> Labels: A
> Fix For: 5.0.0
>
> Attachments: ts153.diff
>
>
> (This is from a Y! Bugzilla ticket 1821593, adding it here. . Originally
> posted by Leif Hedstrom on 2008-03-19):
> Currently you have to set static keep-alive idle timeouts in TS, e.g.
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_in INT 8
> CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 30
> even with epoll() in 1.17.x, this is difficult to configure, and put an
> appropriate timeout. The key here is that the
> settings above need to assure that you stay below the max configured number
> of connections, e.g.:
> CONFIG proxy.config.net.connections_throttle INT 75000
> I'm suggesting that we add one (or two) new configuration options, and
> appropriate TS code support, to instead of
> specifying timeouts, we specify connection limits for idle KA connections.
> For example:
> CONFIG proxy.config.http.keep_alive_max_idle_connections_in INT 50000
> CONFIG proxy.config.http_keep_alive_max_idle_connections_out INT 5000
> (one still has to be careful to leave head-room for active connections here,
> in the example above, 20000 connections
> could be active, which is a lot of traffic).
> These would override the idle timeouts, so one could use the max_idle
> connections for incoming (client) connections,
> and the idle timeouts for outgoing (origin) connections for instance.
> The benefit here is that it makes configuration not only easier, but also a
> lot safer for many applications.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
