[
https://issues.apache.org/jira/browse/TS-4332?focusedWorklogId=26001&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-26001
]
ASF GitHub Bot logged work on TS-4332:
--------------------------------------
Author: ASF GitHub Bot
Created on: 25/Jul/16 22:09
Start Date: 25/Jul/16 22:09
Worklog Time Spent: 10m
Work Description: Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/761
One benefit of the existing throttle approach is that there is a single
limit for both inbound and outbound connections. This allows you to create a
last ditch limit if the number of connections on the current box is overrunning
resources. It can be difficult to compute the max inbound and max outbound
constrained enough to protect the box from resource exhaustion without
overlimiting. That is, I may know that the box has enough memory to support
20K connections, but I don't know if that is 10K inbound and 10K outbound or
15K inbound and 5K outbound.
I think the LRU logic still works to some degree with HTTP/2. I did a bit
of testing there.
Moving forward with the LRU logic, we might want to look at eliminating
some connections from the LRU as well (at least from the closing active
connection phase).
Issue Time Tracking
-------------------
Worklog Id: (was: 26001)
Time Spent: 20m (was: 10m)
> proxy.config.net.connections_throttle should allow for immediate error return
> when accepts reach throttle limit
> ---------------------------------------------------------------------------------------------------------------
>
> Key: TS-4332
> URL: https://issues.apache.org/jira/browse/TS-4332
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
> Reporter: Susan Hinrichs
> Assignee: Susan Hinrichs
> Fix For: sometime
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the throttling kicks in future connections to origins will cause a 502
> to be returned to the user agent.
> But when an accept happens during the throttling period, a message is only
> sent if the unix_netProcessor.throttle_error_message member variable is set.
> In the current code, this member variable is never set. If the variable is
> not set, the logic blocks for 100ms and tries again.
> This spinning causes the ATS process to waste resources. It would be better
> to immediately turn around and send an error response (probably 503 instead
> of 502).
> I tested a build that hard coded an error message and it seemed to recover
> much better.
> I propose adding some config variables to control the throttling behavior.
> proxy.config.connections_throttle.error_code - HTTP response code to return
> (or just hard code this to 503)
> proxy.config.connections_throttle.error_page - Reference to an error page to
> return.
> If both are unset, the existing delaying logic is used. If either is set,
> either a error header or a header and body are returned immediately.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
