[
https://issues.apache.org/jira/browse/TS-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14592694#comment-14592694
]
ASF subversion and git services commented on TS-3488:
-----------------------------------------------------
Commit 692d576c09417dbebcdd184fb995264bb027eb45 in trafficserver's branch
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=692d576 ]
TS-3488] Change some network defines to librecords configurations, and change
defaults
> 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
> Assignee: Leif Hedstrom
> Fix For: 6.0.0
>
>
> 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)
