Increase PMD batch & buffer sizes#481
Conversation
|
Another thing to notice would be the unit test for CWAgent is failing with different OS and its does not relate to our usual flakiness test. Therefore, we would need to deep dive before moving on. |
|
Is the change already deployed on the backend for this? Is there a way for us to manually/automatically integration test just to be sure it works and there isn't any other bottleneck or limiter? |
I don't believe it's tied to any specific OSes but a minor failed test case which should have been fixed.
Are you suggesting the overall code coverage should be bumped up? |
Yes it does not tied to any specific OS. Good job on fixing the test 👍 . However, the GitHub blocks running
Yes. However, it's a no blocker from me. If we confident the existing unit tests has covered enough daily use case then it's fine by me. Another non-block from me would be adding integration test , same as @SaxyPandaBear idea. For the idea, Seth has done similar to this (https://github.com/aws/amazon-cloudwatch-agent/tree/master/integration/test/metrics_number_dimension) |
|
What coverage are you referring to @khanhntd? The change is tiny. Are there specific test cases that you think are missing? Otherwise I don't see what you really think we can improve on test coverage for a one variable change. The only possible thing I could see is integration testing, like what was done for the max dimensions change, but that's not unit test coverage. |
…h-size # Conflicts: # plugins/outputs/cloudwatch/cloudwatch_test.go
Yes. That's why I mentioned its a non-blocker from me consider only the variables change and the test bumping coverage can be done in another PR 👍. |
Codecov Report
@@ Coverage Diff @@
## master #481 +/- ##
==========================================
+ Coverage 56.87% 57.00% +0.12%
==========================================
Files 363 373 +10
Lines 16937 17638 +701
==========================================
+ Hits 9633 10054 +421
- Misses 6753 6993 +240
- Partials 551 591 +40
Continue to review full report at Codecov.
|
|
Is the backend ready for this or are we still waiting? |
| defaultMaxDatumsPerCall = 1000 // PutMetricData only supports up to 1000 data metrics per call by default | ||
| defaultMaxValuesPerDatum = 150 // By default only these number of values can be inserted into the value list | ||
| bottomLinePayloadSizeToPublish = 200000 // Leave 9600B for the last datum buffer. 200KB payload size, 5:1 compression ratio estimate. | ||
| bottomLinePayloadSizeToPublish = 500000 // Leave 2400B for the last datum buffer. 500KB payload size, 5:1 compression ratio estimate. |
There was a problem hiding this comment.
Should sync up with internal: bottomLinePayloadSizeToPublish = 999 000 (0.999 MB) and delete 5:1 compression ratio estimate
There was a problem hiding this comment.
Can you confirm the API limit is actually 1 MiB, as in 1024 * 1024 Bytes?
If so then this limit could be raised to 1023 KiB (1023 * 1024 Bytes).
I don't think it is critical since a payload of 1,000 metric datums is unlikely to reach 1023 KiB.
May as well be as accurate as possible, right?
|
Done in #523 |
Description of the issue
The limit on datum size with
PutMetricDatahas been increased to 1000, and CWA should be aligned with that change in order to send more datums per API call.Description of changes
Increase the default datum size to 1000.
License
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Tests
Running the existing integration test
Requirements
Before commit the code, please do the following steps.
make fmtandmake fmt-shmake linter