- 14 7月, 2021 1 次提交
-
-
由 wu-sheng 提交于
* Performance: remove the synchronous persistence mechanism from batch ElasticSearch DAO. Because the current enhanced persistent session mechanism, don't require the data queryable immediately after the insert and update anymore. * Performance: share `flushInterval` setting for both metrics and record data, due to `synchronous persistence mechanism` removed. Record flush interval used to be hardcoded as 10s. * Remove `syncBulkActions` in ElasticSearch storage option. * Increase the default bulkActions(env, SW_STORAGE_ES_BULK_ACTIONS) to 5000(from 1000). * Increase the flush interval of ElasticSearch indices to 15s(from 10s) Add these 2 references. According to these, **(same _index, _type and _id) in same bulk will be in order** 1. https://github.com/elastic/elasticsearch/issues/50199 2. https://discuss.elastic.co/t/order-of--bulk-request-operations/98124 Notice, the order of different bulks is not guaranteed by the ElasticSearch cluster. We are going to have the risk of dirty write. But consider we set over 20s period between flush, and index flush period is 10, we should be safe. Recommend 5000 bulk size and 15s flush interval only. The persistent period has been set to 25s.
-
- 13 7月, 2021 1 次提交
-
-
由 kezhenxu94 提交于
-
- 11 7月, 2021 1 次提交
-
-
由 Elliot Duan 提交于
Co-authored-by: NElliot Duan <elliot.duan@homecreditcfc.cn>
-
- 10 7月, 2021 1 次提交
-
-
由 Fine0830 提交于
-
- 09 7月, 2021 2 次提交
-
-
由 kezhenxu94 提交于
-
由 kezhenxu94 提交于
Groovy naturally supports many dynamic features that we don't benefit for now but cost performance loss, in this patch we compile our Groovy-based DSL scripts statically to optimize performance.
-
- 08 7月, 2021 2 次提交
-
-
由 Ax1an 提交于
hostInfo.getDatabaseUrl() result in version 8.0.19 or above: jdbc:mysql:loadbalance://**internally_generated**1620805591623** hostInfo.getDatabaseUrl() result in version 8.0.18 or below: jdbc:mysql:replication://127.0.0.1:3306,127.0.0.1:3306,127.0.0.1:3306/mer_goods_admin_sit?useSSL=true&useUnicode=true&autoReconnect=true&rewriteBatchedStatements=TRUE&allowMultiQueries=true&serverTimezone=GMT%2B8
-
由 whl12345 提交于
-
- 07 7月, 2021 1 次提交
-
-
由 Switch 提交于
-
- 06 7月, 2021 1 次提交
-
-
由 Sergi Castro 提交于
* Allow configuring max request header size This allows configuring the HTTP max request header size from the jetty server. By default it uses 8192, the same jetty default.
-
- 05 7月, 2021 1 次提交
-
-
由 Daming 提交于
-
- 04 7月, 2021 1 次提交
-
-
由 Jared Tan 提交于
-
- 03 7月, 2021 3 次提交
- 02 7月, 2021 2 次提交
-
-
由 Linjingchun97 提交于
-
由 AngryMills 提交于
-
- 01 7月, 2021 4 次提交
- 30 6月, 2021 4 次提交
-
-
由 wuweijie@apache.org 提交于
-
由 kezhenxu94 提交于
-
由 wu-sheng 提交于
1.0Performance: Add L1 aggregation flush period, which reduces the CPU load and helps young GC. 2. Replace do not direct send after the first aggregation to reduce the network #6400. 3. Enhance the DataCarrier to notify the consumer in no enqueue event in short term. 4. L1 aggregation flush period still works even no further metrics generated, powered by <3> 5. Fix gRPC remote client OOM. The concurrency control mechanism failed.
-
由 wu-sheng 提交于
* Optimize IDs reading in the persistent worker.
-
- 29 6月, 2021 4 次提交
-
-
由 kezhenxu94 提交于
There are a lot of calls to `Metrics.id()` and `ISource.getEntityId`, which calculates the id by manipulating strings in every single call, producing many garbage objects. In this patch, I cache the id and only calculate the id if it's requested for the first time.
-
由 kezhenxu94 提交于
The possible metrics names are relatively fixed in an OAP run, we previously always escape the metrics names, building a new regex Pattern from scratch, which is cpu-consuming. In this patch, I cache the escaped metrics names, and if it missed, use a pre-compiled regex Pattern to escape the metrics name. This patch also replace string concatenation `+` with `StringBuilder` in generated classes, which won't get optimized by Java compiler This may reduce 1~1.5 vCPU under 20K RPS environment.
-
由 zhyyu 提交于
-
由 Alvin 提交于
-
- 28 6月, 2021 4 次提交
-
-
由 kezhenxu94 提交于
These fields in `stateMap` metadata are not used by `metadata-service-mapping.yaml` now and there is low possibility that they may be used in real case, but, they cost a lot to deserialize, so we remove them to improve performance From what I've tested, the analyzer can process 250k ALS logs before trimming the fields and can process 420k ALS logs after trimming the fields
-
由 liqiangz 提交于
-
由 Fine0830 提交于
-
由 844067874 提交于
-
- 27 6月, 2021 1 次提交
-
-
由 kezhenxu94 提交于
Perf: optimize Envoy ALS analyzer performance in high traffic load scenario (reduce ~1cpu in ~10k RPS) (#7182)
-
- 24 6月, 2021 1 次提交
-
-
由 Daming 提交于
-
- 23 6月, 2021 2 次提交
- 22 6月, 2021 1 次提交
-
-
由 wallezhang 提交于
-
- 20 6月, 2021 2 次提交
-
-
由 kezhenxu94 提交于
-
由 kezhenxu94 提交于
-