[
https://issues.apache.org/jira/browse/CASSANDRA-13031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-13031:
---------------------------------------
Attachment: debug_130131_2.diff
I only ask because I added the timing to try and measure myself and didn't see
a big impact. I am just trying to make sure it has an impact on some use case
before I +1. Most SSDs do pretty fast syncs and most disks on servers also do
pretty fast syncs because they are fronted by a battery backed write cache.
Here are the measurements I just took on my MBP (which yes has a very fast SSD,
and does OS X respect write barriers?). debug=true is supposed to be without
these changes and debug=false is supposed to be with these changes.
||debug=true|debug=false||
|5.144|5.007|
|4.466|4.090|
|4.211|3.922|
|4.040|4.053|
There is an effect where repeated runs after compilation are faster.
> Speed-up start-up sequence by avoiding un-needed flushes
> --------------------------------------------------------
>
> Key: CASSANDRA-13031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13031
> Project: Cassandra
> Issue Type: Bug
> Reporter: Corentin Chary
> Priority: Minor
> Fix For: 3.x
>
> Attachments: 0001-Avoid-un-needed-system-flushes-on-startup.patch,
> debug_130131.diff, debug_130131_2.diff
>
>
> Similar to CASSANDRA-12969, do a conditional update for all functions
> with a forced blocking flush to avoid slowed-down boot sequences. The
> small performance hit of doing a read is always smaller than the one
> associated with a fsync().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)