You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Pavel Kuznetsov (JIRA)" <ji...@apache.org> on 2018/05/16 13:23:00 UTC
[jira] [Updated] (IGNITE-8513) SQL: Write benchmarks to compare
mvcc on/off
[ 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.
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
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 messages count load.
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
> 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.
> 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
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)