Improve Query Performance of Property Store

[CarlChaoCarl]

Rationale

Currently, when the get operation is performed on the snapshot of the property store, the maximum number of layers traversed by the snapshot impl is 20 times. The idea of optimization is that when a snapshot commits, it integrates the full data of the previous snapshot with the incremental data of the current snapshot so that the latest snapshot at the time of commit has the full data. In this way, during the get operation of the property store, the number of layers traversed by the snapshot will be less than or equal to 2 times.

Why should this feature exist?

Improve property store query performance and increase TPS.

Implementation

During initialization, the full data of the snapshotroot is merged into the next snapshot. When the snapshot commits, the incremental data of the current snapshot is merged with the full data in the previous snapshot.

After optimization, when the property store performs a get operation, the value can be found from the incremental data of the snapshot and the full data in the previous snapshot, so that the value can be obtained by traversing at most 2 times. Before the optimization, it needs to traverse up to 20 times to get the value. After optimization, the property store query performance is improved, thereby improving TPS.

[lvs007]

Nice idea, can you provide some test data? How much does the optimization improve performance?

[tomatoishealthy]

Nice idea, can you provide some test data? How much does the optimization improve performance?

Agree, all snapshot r/w operations are at the memory level, and very fast. It may be more convincing to provide more data, such as the ratio of property store access time-consuming to the overall time-consuming. If the ratio is very low, then this optimization may not be effective.

In addition, all snapshots currently use the same code logic. I am curious about how to optimize the property store alone.

[317787106]

Property store has very little data, as it only include some constants, so why it could be traversed up to 20 times ?

[lurais]

@CarlChaoCarl Why just optimize property store but not other stores? Is there any particular reasons?

[eodiandie]

when a snapshot commits, it integrates the full data of the previous snapshot with the incremental data of the current snapshot so that the latest snapshot at the time of commit has the full data.
a small question is whether the optimization(merge current snapshot with exiting full snapshot in every commit) will increase the time consumed by commit action, which will later increase the block execute time?

[CarlChaoCarl]

@CarlChaoCarl Why just optimize property store but not other stores? Is there any particular reasons?

The main reason is that according to the data I have collected, the get frequency of the property store is relatively high, about 100,000 req/s. We optimize the get operation of the property store to improve the TPS of the transaction

@lurais

[CarlChaoCarl]

when a snapshot commits, it integrates the full data of the previous snapshot with the incremental data of the current snapshot so that the latest snapshot at the time of commit has the full data. a small question is whether the optimization(merge current snapshot with exiting full snapshot in every commit) will increase the time consumed by commit action, which will later increase the block execute time?

The commit operation of the snapshot is a low-frequency operation. Currently, a block is committed once at most, that is, once every 3 seconds. It increases the execution time of the block far less than the time saved by the optimization of the get operation.

@xq-lu

[CarlChaoCarl]

Property store has very little data, as it only include some constants, so why it could be traversed up to 20 times ?

When the property store calls the get method, it will call the get method of SnapshotImpl. This method will traverse the snapshot linked list until the value is obtained. Because the memory block solidification requires 19 blocks, it can be traversed up to 20 times.

@317787106

[CarlChaoCarl]

Nice idea, can you provide some test data? How much does the optimization improve performance?

Agree, all snapshot r/w operations are at the memory level, and very fast. It may be more convincing to provide more data, such as the ratio of property store access time-consuming to the overall time-consuming. If the ratio is very low, then this optimization may not be effective.

In addition, all snapshots currently use the same code logic. I am curious about how to optimize the property store alone.

According to the statistics, the get frequency of the property store is relatively high, about 100,000 req/s, and its set operation frequency is relatively low. Compared with other stores, the get frequency is not so high. Optimizing the property store can improve TPS.

@guoquanwu

[CarlChaoCarl]

Nice idea, can you provide some test data? How much does the optimization improve performance?

OK, the following is the tps data obtained from the pressure test in the test environment

1. Hybrid transaction
   The avg tps before optimization is 1086, and the avg tps after optimization is 1178. Compared with TPS, the improvement rate is 8%.
2. Pure TRX transaction
   The avg tps before optimization is 1504, and the avg tps after optimization is 1554. Compared with the improvement ratio, 3%
3. Pure USDT transaction
   The avg tps before optimization is 697, and the avg tps after optimization is 814, compared with an improvement ratio of 16%.

@lvs007

[lvs007]

Can you post your pr?

[CarlChaoCarl]

Can you post your pr?

PR link is as follows：
#5378

@lvs007