[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13830565#comment-13830565
]
Leif Hedstrom commented on TS-153:
----------------------------------
After the discussions at IETF, I really feel we should generalize this, and
augment a lot of the inactivity stuff with LRUs. We would have three LRUs:
1. KA Idle connection LRU
2. Inactive Connection LRU
3. Active Connection LRU
Instead of creating / canceling events for these, we'd simply move connections
between these LRUs as things changes. When you hit the max number of
(configured) client connections, you start in the 1. LRU, and try to reap one
there. If there's nothing to reap, you go to the next LRU (2.) and try to reap
one there. A question would be if it ever makes sense to reap an Active
Connection (3.), but that's something that could be configurable.
In addition to this, we could still honor maximum timeouts for each of these
LRUs. Since each LRU is sorted (by definition), it's easy to process the bottom
portion of each LRU and reap those which are "older" that the configured
maximum. This can be done fairly infrequently (say every 5-10s at the most,
configurable), and would be efficient since you only have to consider those
entries older than a certain age.
This combined I think can eliminate most (all?) of inactivity cop. It also
should (I hope?) be cheaper to maintain these LRUs than the creation and
canceling of all the thousands (millions?) of events constantly. Since a NetVC
can only be in one LRU at any time, it's trivial to manage this, the patch
already adds the plumbing for managing this. What we need is just a state
variable to indicate which LRU the VC is in.
I'd really like to hear from John Plevyak on this bug, and see what he thinks
about moving these inactivity cop / events processing into the general concept
of LRU. Other than performance, the biggest benefit with this work is that it
would be a huge improvement for how people operate and manage their ATS
installations and configurations (no more guessing on timeouts vs conn throttle
setting).
Thanks Bryan for providing this patch!
> "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: 4.2.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.1#6144)
