-
Notifications
You must be signed in to change notification settings - Fork 8.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix issue 673 Make the value of RT_MAX_EXCEED_N in DegradeRule configurable #789
Conversation
using the LongAdder rather than AtomicInteger to Provides better performance
…able make some test
merge master
Codecov Report
@@ Coverage Diff @@
## master #789 +/- ##
============================================
+ Coverage 41.71% 41.87% +0.16%
- Complexity 1376 1386 +10
============================================
Files 304 304
Lines 8764 8778 +14
Branches 1182 1184 +2
============================================
+ Hits 3656 3676 +20
+ Misses 4662 4653 -9
- Partials 446 449 +3
Continue to review full report at Codecov.
|
@@ -55,7 +55,7 @@ | |||
*/ | |||
public class DegradeRule extends AbstractRule { | |||
|
|||
private static final int RT_MAX_EXCEED_N = 5; | |||
private int rtMaxExceedN = RuleConstant.DEGRADE_GRADE_RT_MAX_EXCEED_N; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The RT_MAX_EXCEED_N
has two meanings actually:
- For RT mode, it indicates the minimum number of consecutive slow requests that can trigger RT circuit breaking.
- For exception ratio mode, it indicates the minimum number of requests (in an active statistic time span) that can trigger circuit breaking.
So maybe we need two attributes here? And the attribute name might need to be discussed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hi, @sczyh30
DegradeRule rule = new DegradeRule();
rule.setResource(KEY);
// set limit exception ratio to 0.1
rule.setCount(0.1);
rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO);
rule.setTimeWindow(10);
rule.setRtMaxExceedN(20);
rules.add(rule);
The downgrade rule can only be set to one mode at present. rt mode and exception ratio mode Only one can be selected. The RT_MAX_EXCEED_N attribute can represent different meanings in different modes. So I think that using only one attribute is ok. and you ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They're indeed two different things, so only one attribute might be confusing. I think we can make it two attributes:
rtSlowRequestAmount
for minimum number of consecutive slow requests that can trigger RT circuit breaking.minRequestAmount
for the minimum number of requests (in an active statistic time span) that can trigger circuit breaking.
What do you think of it? @CarpenterLee
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any progress?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
two attribute may be better
Could you please also update the test cases for these two new attributes? |
@sczyh30 Dear sczyh30. I have updated test cases. but i find another potential problem: may be the hashCode() method should consider the problem of numerical out of bounds. |
Maybe overflow isn't a problem for |
ok, I see . Would you view what i had commited is ok or not? |
...emo-basic/src/main/java/com/alibaba/csp/sentinel/demo/degrade/ExceptionRatioDegradeDemo.java
Outdated
Show resolved
Hide resolved
// Will true. While totalQps > minRequestAmount and exceptionCount < minRequestAmount | ||
when(cn.totalQps()).thenReturn(21d); | ||
when(cn.exceptionQps()).thenReturn(19d); | ||
assertTrue(rule.passCheck(context, node, 1)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some problems in the test case. Here successQps
is not provided, so it's by default 0, which does not match the actual relation:
- in the same aligned statistic time window, success (aka. completed count) = exception count + non-exception count (realSuccess)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some problems in the test case. Here
successQps
is not provided, so it's by default 0, which does not match the actual relation:
- in the same aligned statistic time window, success (aka. completed count) = exception count + non-exception count (realSuccess)
Do you mean ?
double realSuccess = success - exception;
if (realSuccess <= 0 && exception < minRequestAmount) {
return true;
}
I am somewhat confused. My understanding is that success is counted when the request should respond successfully. The exception is counted when the program throws a unknown exception. Why do you need a realSuccess? The number of success and excption should be independent of each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name successQps
might be confusing here. The successQps
in Sentinel actually means complete (i.e. passed from Sentinel checking, and has finished invocation, no matter it succeeded or failed logically), so the success count actually includes the exception count. The real success count (what you've understood) should be success - exception
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
understood, the latest code had commit.
@@ -113,8 +113,9 @@ private static void initDegradeRule() { | |||
rule.setResource(KEY); | |||
// set limit exception ratio to 0.1 | |||
rule.setCount(0.1); | |||
rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO); | |||
rule.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_COUNT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be DEGRADE_GRADE_EXCEPTION_RATIO
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Nice work, Thanks for contributing! 👍 |
…butes - improvement of #789 Signed-off-by: Eric Zhao <sczyh16@gmail.com>
Describe what this PR does / why we need it
Make the value of RT_MAX_EXCEED_N in DegradeRule configurable
Does this pull request fix one issue?
fix #673
Describe how you did it
DegradeRule add a new filed rtMaxExceedN to replace RT_MAX_EXCEED_N
Describe how to verify it
Configure rtMaxExceedN to see if it takes effect.
Special notes for reviews