ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Kuznetsov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-8513) SQL: Write benchmarks to compare mvcc on/off
Date Wed, 16 May 2018 13:31:00 GMT

     [ 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)

Mime
View raw message