Leif Hedstrom created TS-3488:
---------------------------------
Summary: Tune and configure some NET constants
Key: TS-3488
URL: https://issues.apache.org/jira/browse/TS-3488
Project: Traffic Server
Issue Type: Improvement
Components: Configuration, Network
Reporter: Leif Hedstrom
I'm thinking these should at least be tuned (20 seems better):
{code}
#define NET_PERIOD -HRTIME_MSECONDS(5)
#define ACCEPT_PERIOD -HRTIME_MSECONDS(4)
{code}
(they used to be 20, bcall checked for me in old code repos, thanks!).
I think this one should be configurable in some way:
{code}
#define NET_RETRY_DELAY HRTIME_MSECONDS(10)
{code}
I think increasing this could introduce latency in some cases, but could also
reduce the amount of lock retries and hence reduce pressure on event system and
core (under high load).
>From the discussions on IRC with amc and jpeach, one consensus seems to be
>that we should do this for anything configurable:
1) Set a minimum, based on CLK_TCK (e.g. 10 on linux)
2) Make configurable options (if any) such that they are multipliers based on
CLK_TCK (so, 10, 20, 30 etc. on Linux).
In any case, at a minimum I'd like to see
{code}
-#define NET_PERIOD -HRTIME_MSECONDS(5)
-#define ACCEPT_PERIOD -HRTIME_MSECONDS(4)
+#define NET_PERIOD -HRTIME_MSECONDS(20)
+#define ACCEPT_PERIOD -HRTIME_MSECONDS(20)
{code}
And something that allows NET_RETRY_DELAY to be configurable (either
records.config or configure.ac)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
