[
https://issues.apache.org/jira/browse/CASSANDRA-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13969736#comment-13969736
]
Benedict commented on CASSANDRA-7040:
-------------------------------------
bq. You could add in helpers like mincore (and row cache) to help inform you
Or CASSANDRA-5863 :-)
As to batching - that's another step further along: it would be interesting to
experiment with an intelligent "storage manager" that requests are submitted
to, and are coordinated by, but I think that comes after 5863 + this. There's
lots of ways we might be able to get improved performance with that approach,
but I'm not absolutely sure they'll pan out, and they'll be a non-trivial
undertaking.
> Replace read/write stage with per-disk access coordination
> ----------------------------------------------------------
>
> Key: CASSANDRA-7040
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7040
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Labels: performance
> Fix For: 3.0
>
>
> As discussed in CASSANDRA-6995, current coordination of access to disk is
> suboptimal: instead of ensuring disk accesses alone are coordinated, we
> instead coordinate at the level of operations that may touch the disks,
> ensuring only so many are proceeding at once. As such, tuning is difficult,
> and we incur unnecessary delays for operations that would not touch the
> disk(s).
> Ideally we would instead simply use a shared coordination primitive to gate
> access to the disk when we perform a rebuffer. This work would dovetail very
> nicely with any work in CASSANDRA-5863, as we could prevent any blocking or
> context switching for data that we know to be cached. It also, as far as I
> can tell, obviates the need for CASSANDRA-5239.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
