[ https://issues.apache.org/jira/browse/CASSANDRA-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13984597#comment-13984597 ]
Joshua McKenzie edited comment on CASSANDRA-7001 at 4/29/14 6:04 PM: --------------------------------------------------------------------- While doing some win7 bare-metal vs. ubuntu 14.04 bare-metal performance comparisons I came across the fact that my env changes broke VisualGC functionality. Took some digging, but it turns out that * the cygwin install I had on my previous win8 config was screwing with the TMP/TEMP environment variables and getting in the way of .NET's invoking of libraries from powershell. Clearing those variables wasn't strictly necessary, and... * if you clear TMP and TEMP before invoking a jvm, it doesn't know where to put some files that are necessary for jps, visualgc, and likely some other utilities to work. I've attached a v2 that fixes that. As for the performance front - Windows writes look to be about 6% slower than linux at saturation. On the read front it looks like Windows is much more CPU-heavy without memory-mapped I/O than linux - 4 HT haswell peg at 100% on 54 threads vs. linux at 181, however with memory-mapped index file I/O Windows read performance looks surprisingly good. I'm planning on shelving performance profiling until after cleaning up the unit and dtests, but I wanted to have a general baseline of where we are currently as well as confirm no performance regressions from this patch. Edit: I should clarify - the tests vs. OSX earlier had the stress client running on the same machine as the cassandra instance. Given Windows being CPU-bottlenecked on buffered I/O, the # of threads on the stress client were mucking with the results. was (Author: joshuamckenzie): While doing some win7 bare-metal vs. ubuntu 14.04 bare-metal performance comparisons I came across the fact that my env changes broke VisualGC functionality. Took some digging, but it turns out that * the cygwin install I had on my previous win8 config was screwing with the TMP/TEMP environment variables and getting in the way of .NET's invoking of libraries from powershell. Clearing those variables wasn't strictly necessary, and... * if you clear TMP and TEMP before invoking a jvm, it doesn't know where to put some files that are necessary for jps, visualgc, and likely some other utilities to work. I've attached a v2 that fixes that. As for the performance front - Windows writes look to be about 6% slower than linux at saturation. On the read front it looks like Windows is much more CPU-heavy without memory-mapped I/O than linux - 4 HT haswell peg at 100% on 54 threads vs. linux at 181, however with memory-mapped index file I/O Windows read performance looks surprisingly good. I'm planning on shelving performance profiling until after cleaning up the unit and dtests, but I wanted to have a general baseline of where we are currently as well as confirm no performance regressions from this patch. > Windows launch feature parity - augment launch process using PowerShell to > match capabilities of *nix launching > --------------------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-7001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7001 > Project: Cassandra > Issue Type: Improvement > Reporter: Joshua McKenzie > Assignee: Joshua McKenzie > Fix For: 2.1 rc1 > > Attachments: 7001_v1.txt, 7001_v2.txt > > > The current .bat-based launching has neither the logic nor robustness of a > bash or PowerShell-based solution. In pursuit of making Windows a 1st-class > citizen for C*, we need to augment the launch-process using something like > PowerShell to get as close to feature-parity as possible with Linux. -- This message was sent by Atlassian JIRA (v6.2#6252)