wu-sheng opened a new pull request, #10127:
URL: https://github.com/apache/skywalking/pull/10127
<!--
⚠️ Please make sure to read this template first, pull requests that
don't accord with this template
maybe closed without notice.
Texts surrounded by `<` and `>` are meant to be replaced by you, e.g.
<framework name>, <issue number>.
Put an `x` in the `[ ]` to mark the item as CHECKED. `[x]`
-->
<!-- ==== 🐛 Remove this line WHEN AND ONLY WHEN you're fixing a bug, follow
the checklist 👇 ====
### Fix <bug description or the bug issue number or bug issue link>
- [ ] Add a unit test to verify that the fix works.
- [ ] Explain briefly why the bug exists and how to fix it.
==== 🐛 Remove this line WHEN AND ONLY WHEN you're fixing a bug, follow
the checklist 👆 ==== -->
<!-- ==== 📈 Remove this line WHEN AND ONLY WHEN you're improving the
performance, follow the checklist 👇 ====
### Improve the performance of <class or module or ...>
- [ ] Add a benchmark for the improvement, refer to [the existing
ones](https://github.com/apache/skywalking/blob/master/apm-commons/apm-datacarrier/src/test/java/org/apache/skywalking/apm/commons/datacarrier/LinkedArrayBenchmark.java)
- [ ] The benchmark result.
```text
<Paste the benchmark results here>
```
- [ ] Links/URLs to the theory proof or discussion articles/blogs.
<links/URLs here>
==== 📈 Remove this line WHEN AND ONLY WHEN you're improving the
performance, follow the checklist 👆 ==== -->
<!-- ==== 🆕 Remove this line WHEN AND ONLY WHEN you're adding a new feature,
follow the checklist 👇 ====
### <Feature description>
- [ ] If this is non-trivial feature, paste the links/URLs to the design doc.
- [ ] Update the documentation to include this new feature.
- [ ] Tests(including UT, IT, E2E) are added to verify the new feature.
- [ ] If it's UI related, attach the screenshots below.
==== 🆕 Remove this line WHEN AND ONLY WHEN you're adding a new feature,
follow the checklist 👆 ==== -->
- [ ] If this pull request closes/resolves/fixes an existing issue, replace
the issue number. Closes #<issue number>.
- [x] Update the [`CHANGES`
log](https://github.com/apache/skywalking/blob/master/docs/en/changes/changes.md).
I deeply run some research on ElasticSearch and asked for help from the
Elastic China team.
From ElasticSearch 6.0, the operation for the doc has seg to guarantee the
order.
Ref https://www.elastic.co/cn/blog/elasticsearch-sequence-ids-6-0
From what the seg was introduced, we should be confident that `reflush
period` doesn't have to be short.
Ref from official doc,
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html#_unset_or_increase_the_refresh_interval
Ref from an old blog,
https://sematext.com/blog/elasticsearch-refresh-interval-vs-indexing-performance/
They all show a longer refresh period could bring higher performance.
Finally, in our current case, 30s latency to show metrics should be a good
balance point. As usual, the persistent period is 25s. @kezhenxu94 @wankai123
Does this make sense?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
