[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14294308#comment-14294308 ] ASF subversion and git services commented on TS-153: Commit c53eb2e011b271db672c299b8fa4049be210ce4b in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=c53eb2e ] TS-153: Fixed typo on method name 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288645#comment-14288645 ] ASF subversion and git services commented on TS-153: Commit abe6035641ef4b00e14c3e9b87fc616eba345a03 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=abe6035 ] TS-153: Fixed warning of unused argument 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288541#comment-14288541 ] ASF subversion and git services commented on TS-153: Commit ab3fec0a88aba5bf8da5078ea0ab326e4fd61988 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ab3fec0 ] TS-153: Dynamic keep-alive timeouts Updates after a code review with AMC and more testing 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288565#comment-14288565 ] ASF subversion and git services commented on TS-153: Commit 9763a7f87a1cf7e3a6df20edc7bf19bf99965663 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9763a7f ] TS-153: Dynamic keep-alive timeouts Removed an unneed removal from the LRU. 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14288581#comment-14288581 ] ASF subversion and git services commented on TS-153: Commit b48c343e6bbc58527b875fef31cbc1c8349fc650 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=b48c343 ] TS-153: Forgot to add the abort after removing the assert when a stat can't be fetched in traffic_top 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286022#comment-14286022 ] ASF subversion and git services commented on TS-153: Commit 5e91acd24e67da73baa81ded14878e32273f1e20 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5e91acd ] TS-153: Dynamic keep-alive timeouts 1. Changed the limit on the number of connections to include all incoming connections instead of just ones that are keep-alive. This will keep the number of incoming connections per thread more consistent. However, it will only close keep-alive connections. 2. Change the double link list to a queue. 3. When adding to the queue if the connection is already in the queue remove it and then add it to the end the queue. 4. Properly close the connection by mimicking what inactivity cop does to close the connection. 5. Add stats to determine the average KA timeout since it is now dynamic. 6. Added support for spdy connections. Config option is now: proxy.config.net.connections.threshold_shed_idle_in Stats added are: proxy.process.net.dynamic_keep_alive_timeout_in_total proxy.process.net.dynamic_keep_alive_timeout_in_count 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286467#comment-14286467 ] ASF subversion and git services commented on TS-153: Commit 1dfc029c78bd986e42fcd10a2a30f94aa8f54e7a in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1dfc029 ] TS-153: Updates to traffic_top to report dynamic KA times 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14286508#comment-14286508 ] ASF subversion and git services commented on TS-153: Commit 0b7bf112a778111469f837a3fbba3982d217bb5d in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0b7bf11 ] TS-153: Dynamic keep-alive timeouts Renaming proxy.config.net.connections.threshold_shed_idle_in to proxy.config.net.max_connections_in to be inline with the overall design in TS-3312 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280710#comment-14280710 ] David Carlin commented on TS-153: - amc/sudheerv came up with proxy.config.connections.threshold_shed_idle - I like that, its succinct and is very descriptive about whats accomplished with this setting 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280762#comment-14280762
]
Bryan Call commented on TS-153:
---
proxy.config.connections doesn't exit that is why I picked proxy.config.net.
Also, the name should have _in in it since it is for incoming connections:
I would be find with {{proxy.config.net.threshold_shed_idle_in}}
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.3.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 5
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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280769#comment-14280769 ] David Carlin commented on TS-153: - proxy.config.net.threshold_shed_idle_in is good 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.3.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 5 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, 2 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.3.4#6332)
Re: [jira] [Commented] (TS-153) Dynamic keep-alive timeouts
There was another Jira on a similar issue. My concern on that one, and same here, is how all these connection limits relates to the amount of FDs that we ask for. Today the throttling setting is used for setrlimit, but as we add these new settings I think we need to revisit this. An overhaul of connection limits is in order IMO, to minimize confusion and obfuscation. -- Leif On Jan 16, 2015, at 1:14 PM, David Carlin (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280769#comment-14280769 ] David Carlin commented on TS-153: - proxy.config.net.threshold_shed_idle_in is good 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14280876#comment-14280876
]
Sudheer Vinukonda commented on TS-153:
--
Thanks, [~bcall] - Yes, I think {{proxy.config.net.threshold_shed_idle_in}}
sounds better, although, it doesn't say what it's shedding :) - would
{{proxy.config.net.threshold_shed_idle_connections_in}} sound better?
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.3.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 5
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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14247122#comment-14247122 ] ASF subversion and git services commented on TS-153: Commit ce08ae8a88b15cda917484197e75e524456d0a5d in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ce08ae8 ] TS-153: Dynamic keep-alive timeouts for incoming connections 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14247170#comment-14247170
]
Sudheer Vinukonda commented on TS-153:
--
I think {{ remove_from_keep_alive_lru() }} should also be called from {{
HttpClientSession::do_io_close() }}, else there may be a danger of a double
release for an already released netvc?
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.3.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 5
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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14247551#comment-14247551 ] ASF subversion and git services commented on TS-153: Commit 04871a9742ccb055ddfbd7f0dbe1cce4c3348cb6 in trafficserver's branch refs/heads/master from [~bcall] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=04871a9 ] TS-153: fixed singed/unsinged compare 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.3.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 5 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, 2 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.3.4#6332)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[ https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13922316#comment-13922316 ] Leif Hedstrom commented on TS-153: -- 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 5 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, 2 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)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13817792#comment-13817792
]
Bryan Call commented on TS-153:
---
Production debug output running with 20 threads and the limit set to 500.
Sill need to make changes to the configuration to make it more user friendly.
{code}
[Nov 8 22:46:05.773] Server {0x2b8803f4e700} ERROR: keep alive lru size: 506
max: 500 total: 571
[Nov 8 22:46:05.787] Server {0x2b8801d823a0} ERROR: keep alive lru size: 513
max: 500 total: 568
[Nov 8 22:46:05.788] Server {0x2b8808504700} ERROR: keep alive lru size: 509
max: 500 total: 571
[Nov 8 22:46:05.797] Server {0x2b8808b0a700} ERROR: keep alive lru size: 505
max: 500 total: 561
[Nov 8 22:46:05.889] Server {0x2b8808403700} ERROR: keep alive lru size: 509
max: 500 total: 552
[Nov 8 22:46:05.889] Server {0x2b8803847700} ERROR: keep alive lru size: 504
max: 500 total: 560
[Nov 8 22:46:05.889] Server {0x2b8803b4a700} ERROR: keep alive lru size: 515
max: 500 total: 562
[Nov 8 22:46:05.889] Server {0x2b8808605700} ERROR: keep alive lru size: 507
max: 500 total: 564
[Nov 8 22:46:05.889] Server {0x2b8803948700} ERROR: keep alive lru size: 510
max: 500 total: 572
{code}
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 5
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, 2 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)
[jira] [Commented] (TS-153) Dynamic keep-alive timeouts
[
https://issues.apache.org/jira/browse/TS-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13815151#comment-13815151
]
Bryan Call commented on TS-153:
---
investigating the current timeouts here debug output of setting the timeouts on
a single forward proxy requests:
{code}
[Nov 6 10:55:50.819] Server {0x10e59b000} DEBUG: (socket) Set inactive
timeout=1200, for NetVC=0x7fa9a3855160
[Nov 6 10:55:50.819] Server {0x10e59b000} DEBUG: (socket) Set active
timeout=9000, NetVC=0x7fa9a3855160
[Nov 6 10:55:50.819] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 1200, NetVC=0x7fa9a3855160
[Nov 6 10:55:50.819] Server {0x10e59b000} DEBUG: (socket) Set inactive
timeout=300, for NetVC=0x7fa9a3855160
[Nov 6 10:55:50.819] Server {0x10e59b000} DEBUG: (socket) read_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:50.865] Server {0x10e59b000} DEBUG: (socket) Cancel inactive
timeout for NetVC=0x7fa9a3855160
[Nov 6 10:55:50.865] Server {0x10e59b000} DEBUG: (socket) Set inactive
timeout=300, for NetVC=0x7fa9a3850d20
[Nov 6 10:55:50.865] Server {0x10e59b000} DEBUG: (socket) Set active
timeout=0, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.065] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.602] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.602] Server {0x10e59b000} DEBUG: (socket) Set inactive
timeout=300, for NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.603] Server {0x10e59b000} DEBUG: (socket) Set inactive
timeout=300, for NetVC=0x7fa9a3855160
[Nov 6 10:55:51.603] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.603] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.604] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.604] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.604] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.802] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.802] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.802] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.802] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.993] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:51.993] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:51.993] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.046] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:52.046] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.046] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.059] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:52.059] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:52.059] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.059] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.069] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:52.069] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.069] Server {0x10e59b000} DEBUG: (socket) write_disable
updating inactivity_at 0, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.238] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:52.238] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3850d20
[Nov 6 10:55:52.238] Server {0x10e59b000} DEBUG: (socket) net_activity
updating inactivity 300, NetVC=0x7fa9a3855160
[Nov 6 10:55:52.238] Server {0x10e59b000} DEBUG: (socket) write_disable
updating
