[ https://issues.apache.org/jira/browse/IGNITE-8513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Kuznetsov updated IGNITE-8513: ------------------------------------ Description: We need to compare performance with mvcc turned on and off. Development branch is ignite-4191 Scope All benchmarks uses native sql api cache.query(SqlFieldsQuery) We are using simplified data model: table containing long PK and 1 long value field. 1) Measure increased load of messages. 1 client node and many (4) server nodes. Benchmark does updates in single thread. backups = 0, 2 2) Measure contention on mvcc processor. Many client nodes (4) and 1 server node. Benchmark performs updates in many threads. Threads use keys from *disjoint* ranges. backups = 0 3) Measure contention on updates. 4 client nodes and 2 server nodes. Benchmark performs updates in many threads. Thread use keys from *intersecting* ranges. Exceptions due to write conflicts should be just ignored. Update keys should be sorted to prevent dead locks in current implementation. backups = 0 Common parameters: atomicity mode = transactional cache mode = partitioned persistence = off some benchmark code can be reused from IGNITE-7988 was: We need to compare performance with mvcc turned on and off. Development branch is ignite-4191 Scope All benchmarks uses native sql api cache.query(SqlFieldsQuery) We are using simplified data model: table containing long PK and 1 long value field. 1) Measure increased load of messages. 1 client node and many (4) server nodes. Benchmark does updates in single thread. 2) Measure contention on mvcc processor. Many client nodes (4) and 1 server node. Benchmark performs updates in many threads. Threads use keys from *disjoint* ranges. 3) Measure contention on updates. 4 client nodes and 2 server nodes. (?) Benchmark performs updates in many threads. Thread use keys from *intersecting* ranges. Exceptions due to contention of updating the same key should be just ignored. update keys order should be sorted. Common parameters: backups count = 0 (?) atomicity mode = transactional cache mode = partitioned persistence = off some benchmark code can be reused from IGNITE-7988 > SQL: Write benchmarks to compare mvcc on/off > -------------------------------------------- > > Key: IGNITE-8513 > URL: https://issues.apache.org/jira/browse/IGNITE-8513 > Project: Ignite > Issue Type: Task > Reporter: Pavel Kuznetsov > Assignee: Pavel Kuznetsov > Priority: Major > > We need to compare performance with mvcc turned on and off. > Development branch is ignite-4191 > Scope > All benchmarks uses native sql api cache.query(SqlFieldsQuery) > We are using simplified data model: table containing long PK and 1 long value > field. > 1) Measure increased load of messages. > 1 client node and many (4) server nodes. > Benchmark does updates in single thread. > backups = 0, 2 > 2) Measure contention on mvcc processor. > Many client nodes (4) and 1 server node. > Benchmark performs updates in many threads. Threads use keys from *disjoint* > ranges. > backups = 0 > 3) Measure contention on updates. > 4 client nodes and 2 server nodes. > Benchmark performs updates in many threads. Thread use keys from > *intersecting* ranges. > Exceptions due to write conflicts should be just ignored. > Update keys should be sorted to prevent dead locks in current implementation. > backups = 0 > Common parameters: > atomicity mode = transactional > cache mode = partitioned > persistence = off > some benchmark code can be reused from IGNITE-7988 -- This message was sent by Atlassian JIRA (v7.6.3#76005)