[jira] [Comment Edited] (CASSANDRA-7001) Windows launch feature parity - augment launch process using PowerShell to match capabilities of *nix launching

["Joshua McKenzie (JIRA)" <ji...@apache.org>]

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