Skip to content
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

Merged
merged 13 commits into from
Jun 14, 2019
Merged

Fix issue 673 Make the value of RT_MAX_EXCEED_N in DegradeRule configurable #789

merged 13 commits into from
Jun 14, 2019

Conversation

linlinisme
Copy link
Collaborator

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

@codecov-io
Copy link

codecov-io commented May 25, 2019

Codecov Report

Merging #789 into master will increase coverage by 0.16%.
The diff coverage is 63.63%.

Impacted file tree graph

@@             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
Impacted Files Coverage Δ Complexity Δ
...a/com/alibaba/csp/sentinel/node/StatisticNode.java 55.68% <100%> (ø) 27 <0> (ø) ⬇️
.../csp/sentinel/slots/block/degrade/DegradeRule.java 62.1% <57.89%> (+6.54%) 23 <3> (+6) ⬆️
...a/csp/sentinel/slots/statistic/base/LeapArray.java 70.29% <0%> (+2.97%) 34% <0%> (+1%) ⬆️
...alibaba/csp/sentinel/slots/block/AbstractRule.java 58.62% <0%> (+10.34%) 14% <0%> (+3%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 062385f...11cbc7f. Read the comment docs.

@sczyh30 sczyh30 added the to-review To review label May 25, 2019
@@ -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;
Copy link
Member

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.

Copy link
Collaborator Author

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 ?

Copy link
Member

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any progress?

Copy link
Collaborator Author

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

@sczyh30
Copy link
Member

sczyh30 commented Jun 5, 2019

Could you please also update the test cases for these two new attributes?

@linlinisme
Copy link
Collaborator Author

linlinisme commented Jun 6, 2019

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.

@sczyh30
Copy link
Member

sczyh30 commented Jun 10, 2019

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: maybe the hashCode() method should consider the problem of numerical out of bounds.

Maybe overflow isn't a problem for hashCode() as long as it could achieve good dispersion and uniqueness.

@linlinisme
Copy link
Collaborator Author

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: maybe the hashCode() method should consider the problem of numerical out of bounds.

Maybe overflow isn't a problem for hashCode() as long as it could achieve good dispersion and uniqueness.

ok, I see . Would you view what i had commited is ok or not?

// Will true. While totalQps > minRequestAmount and exceptionCount < minRequestAmount
when(cn.totalQps()).thenReturn(21d);
when(cn.exceptionQps()).thenReturn(19d);
assertTrue(rule.passCheck(context, node, 1));
Copy link
Member

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)

Copy link
Collaborator Author

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.

Copy link
Member

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.

Copy link
Collaborator Author

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);
Copy link
Member

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?

Copy link
Member

@sczyh30 sczyh30 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sczyh30 sczyh30 merged commit 2eecd3a into alibaba:master Jun 14, 2019
@sczyh30
Copy link
Member

sczyh30 commented Jun 14, 2019

Nice work, Thanks for contributing! 👍
I'll refine the naming of some constants later.

@sczyh30 sczyh30 added this to the 1.7.0 milestone Nov 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make the value of RT_MAX_EXCEED_N in DegradeRule configurable
3 participants