{"componentChunkName":"component---src-templates-tags-js","path":"/tags/testing/1","result":{"pageContext":{"tag":"testing","urlTag":"testing","chunk":[{"content":"

{{ message }}

\n
\n
\n

You can’t perform that action at this time.

\n

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

\n
\n\n
","id":"166bfd43-cfec-506b-be68-f384b93820b4","title":"GitHub - apache/cassandra-harry: Apache Cassandra - Harry","origin_url":"https://github.com/apache/cassandra-harry","url":"https://github.com/apache/cassandra-harry","wallabag_created_at":"2022-06-08T20:37:16+00:00","published_at":null,"published_by":"['apache']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/aa15162e4aac1bfa5fbd58f2757de131eaa602ad2bc71025321e6eeb66ff4553/apache/cassandra-harry","tags":["cassandra","testing"],"description":"{{ message }}\n / cassandra-harry PublicNotifications\nFork 12\n\n Star 43 \n\nApache Cassandra - Harrycassandra.apache.org/License Apache-2.0 license 43 stars 12 forks Star Notifications\n\n © 2022 GitHub, ..."},{"content":"

{{ message }}

\n
\n
\n

You can’t perform that action at this time.

\n

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

\n
","id":"d29b900a-7c3e-537e-a25e-6c8caff38e03","title":"GitHub - apache/cassandra-diff: Apache cassandra diff","origin_url":"https://github.com/apache/cassandra-diff","url":"https://github.com/apache/cassandra-diff","wallabag_created_at":"2022-06-08T20:37:07+00:00","published_at":null,"published_by":"['']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/e7a10c615cc491e34c4e3f952c02c227c9b02a49ab4ccf2ebd3bc5832f285203/apache/cassandra-diff","tags":["cassandra","testing"],"description":"{{ message }}\nApache cassandra diffcassandra.apache.org/LicenseApache-2.0 license10 stars 16 forks\n\n© 2022 GitHub, Inc.\n\nYou can’t perform that action at this time.\nYou signed in with another tab or w..."},{"content":"

{{ message }}

\n

/ adelphi Public

Automation tool for testing C* OSS that assembles cassandra-diff, nosqlbench, fqltool

License

Apache-2.0 license

9 stars 4 forks

Star

Notifications

\n
\n

You can’t perform that action at this time.

\n

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

\n
\n\n
","id":"75fb8bf0-c48c-58d3-b5ef-b60dc7508eb1","title":"GitHub - datastax/adelphi: Automation tool for testing C* OSS that assembles cassandra-diff, nosqlbench, fqltool","origin_url":"https://github.com/datastax/adelphi","url":"https://github.com/datastax/adelphi","wallabag_created_at":"2022-06-08T20:36:15+00:00","published_at":null,"published_by":"['datastax']","reading_time":null,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/afe20d0322f42c980557122f254ed0db1a89239e8a1e4130618ed630ed786ddc/datastax-archive/adelphi","tags":["stress","cassandra","cassandra.stress","testing"],"description":"{{ message }}\n / adelphi PublicNotifications\nFork 4\n\n Star 9 \n\nAutomation tool for testing C* OSS that assembles cassandra-diff, nosqlbench, fqltoolLicense Apache-2.0 license 9 stars 4 forks Star Not..."},{"content":"
\n

This is a sample code of utilizing Gatling testing framework for stress testing with DSE

\n

Pre-requisites

\n

Note: At the moment, the latest version of Gatling framework is 2.3.1. However, the CQL plugin 0.0.7 is not compatible with Gatling 2.3.1 yet.

\n
  1. Gatling high charts bundle version 2.2.5:
    2. \n
  1. Gatling CQL plugin v0.0.7 (latest version as of writing)
    2. \n

[NOTES] - as of April 10, 2018, Gatling CQL plugin has released version 0.0.8 which works with the latest Gatling framework 2.3.1. Please feel free to download these latest versions for your test. Please also be aware that Gatling 2.3.1 requires scala 2.1.2 and make sure your scala version is upgraded first.

\n

Notes about the Example Simulation Scenario

\n

The simulation scenario (MyTestSimu.scala) as included in this example simulates a mixed read/write workload. The core steps of the scenario are summarized below and you can follow the same steps when creating your own scenario:

\n
  1. Set up connection to Cassandra/DSE cluster with proper properties, such as \"contact points\", \"load balancing policy\", etc.
    2. \n
  2. Create the application keyspace and table schema
    3. \n
  3. Define the (random) value generator for table columns based on their types
    4. \n
  4. Define the Read/Write statements to be used in the simulation, including the Consistency Level associated with the statements
    5. \n
  5. Set up the user simulation behavior for Read and Write. The key parts include:
    6. \n

Procedure

\n
  1. Set up Gatling framework and the CQL plug-in (just unzip, as per description found here)
    2. \n
  2. Download the MyTestSimu.scala file and put it under folder <GATLING_HOME>/user-files/simulations/
    3. \n
  3. Execute the Gatling simulation (stress-testing) scenario by running command: <GATLING_HOME>/bin/gatling.sh. Follow the instructions on the command-line output.
    4. \n

NOTE: The simulation scenario (MyTestSimu.scala) is tested against a DSE cluster (version 5.1.6) with UserName/Password authentication. Please adjust accordingly for your case.

\n

An example is as below. Simulation number 1 is the Cassandra stres-testing scenario as defined by this example.

\n
$ bin/gatling.sh\nGATLING_HOME is set to /home/automaton/gatling-charts-highcharts-bundle-2.2.5\nChoose a simulation number:\n     [0] cassandra.CassandraSimulation\n     [1] cassandra.MyTestSimu\n     [2] computerdatabase.BasicSimulation\n     [3] computerdatabase.advanced.AdvancedSimulationStep01\n     [4] computerdatabase.advanced.AdvancedSimulationStep02\n     [5] computerdatabase.advanced.AdvancedSimulationStep03\n     [6] computerdatabase.advanced.AdvancedSimulationStep04\n     [7] computerdatabase.advanced.AdvancedSimulationStep05\n1\nSelect simulation id (default is 'mytestsimu'). Accepted characters are a-z, A-Z, 0-9, - and _\nSelect run description (optional)\nSimulation cassandra.MyTestSimu started...\n================================================================================\n2018-04-04 15:33:43                                           5s elapsed\n---- Requests ------------------------------------------------------------------\n> Global                                                   (OK=232    KO=0     )\n> upsertStmt                                               (OK=93     KO=0     )\n> readStmt                                                 (OK=139    KO=0     )\n---- Read Workload Scenario ----------------------------------------------------\n[#                                                                         ]  1%\n          waiting: 8861   / active: 0      / done:139\n---- Write Workload Scenario ---------------------------------------------------\n[                                                                          ]  0%\n          waiting: 20907  / active: 0      / done:93\n================================================================================\n... ...\n================================================================================\n2018-04-04 15:43:39                                         600s elapsed\n---- Requests ------------------------------------------------------------------\n> Global                                                   (OK=30000  KO=0     )\n> upsertStmt                                               (OK=21000  KO=0     )\n> readStmt                                                 (OK=9000   KO=0     )\n---- Read Workload Scenario ----------------------------------------------------\n[##########################################################################]100%\n          waiting: 0      / active: 0      / done:9000\n---- Write Workload Scenario ---------------------------------------------------\n[##########################################################################]100%\n          waiting: 0      / active: 0      / done:21000\n================================================================================\nSimulation cassandra.MyTestSimu completed in 600 seconds\nParsing log file(s)...\nParsing log file(s) done\nGenerating reports...\n================================================================================\n---- Global Information --------------------------------------------------------\n> request count                                      30000 (OK=30000  KO=0     )\n> min response time                                      0 (OK=0      KO=-     )\n> max response time                                    224 (OK=224    KO=-     )\n> mean response time                                     2 (OK=2      KO=-     )\n> std deviation                                          5 (OK=5      KO=-     )\n> response time 50th percentile                          1 (OK=1      KO=-     )\n> response time 75th percentile                          2 (OK=2      KO=-     )\n> response time 95th percentile                          3 (OK=3      KO=-     )\n> response time 99th percentile                          7 (OK=7      KO=-     )\n> mean requests/sec                                     50 (OK=50     KO=-     )\n---- Response Time Distribution ------------------------------------------------\n> t < 800 ms                                         30000 (100%)\n> 800 ms < t < 1200 ms                                   0 (  0%)\n> t > 1200 ms                                            0 (  0%)\n> failed                                                 0 (  0%)\n================================================================================\nReports generated in 4s.\nPlease open the following file: /home/automaton/gatling-charts-highcharts-bundle-2.2.5/results/mytestsimu-1522856018600/index.html\n
\n
","id":"22b64c72-6b88-5842-8e08-ebff60cc319b","title":"yabinmeng/cassgatling","origin_url":"https://github.com/yabinmeng/cassgatling","url":"https://github.com/yabinmeng/cassgatling","wallabag_created_at":"2018-11-14T17:34:32+00:00","published_at":null,"published_by":null,"reading_time":3,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/ba96401352e04a099abef2d795d350d978caf9070e2f7cf302b70025f16fcffd/yabinmeng/cassgatling","tags":["stress","cassandra","gatling","testing"],"description":"\nThis is a sample code of utilizing Gatling testing framework for stress testing with DSE\nPre-requisites\nNote: At the moment, the latest version of Gatling framework is 2.3.1. However, the CQL plugin ..."},{"content":"
\n

Methodology

\n

Breakdown the switches!

\n

I told you that this would be educational!

\n

First test

\n

cassandra-stress user profile=stress.yaml n=1000000 ops\\(insert=3,likelyquery1=1\\) cl=QUORUM -mode native cql3 user=cassandra password=datastax -node 104.196.140.126 -rate threads\\>=121

\n

Second test

\n

I am not going to go over the flags/arguments that I went over in the previous example. Instead, I'll go over the new ones or changes.

\n

nohup cassandra-stress user profile=stress.yaml n=1000000000 ops\\(insert=3,likelyquery1=1\\) cl=QUORUM -mode native cql3 user=cassandra password=datastax -node 40.118.149.27 -rate threads=300 -log file=output.txt -errors ignore

\n

Results

\n

to be continued... maybe, if I can.

\n\n

Thanks for taking a look at this repo and let me know if you have any questions.

\n
","id":"c7ef4299-9aed-5814-830c-152a2c71eee3","title":"justinbreese/dse-cassandra-stress","origin_url":"https://github.com/justinbreese/dse-cassandra-stress","url":"https://github.com/justinbreese/dse-cassandra-stress","wallabag_created_at":"2018-11-13T20:12:27+00:00","published_at":null,"published_by":null,"reading_time":5,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/ad3b3ac83d6bdca681e5fa455a46e248f827c4ef3fed9166b05113d5ea996ee6/justinbreese/dse-cassandra-stress","tags":["stress","cassandra","dse","testing","aws","google.cloud","azure"],"description":"\nI wanted to run some cassandra-stress testing on the three main cloud providers (Google, Amazon, and Microsoft) on similarly sized DataStax Enterprise clusters and see what the results would be\nWhy d..."},{"content":"

Developing software is fun. Developing software that is well tested, where those tests run quickly is even more fun.

Stubbed Cassandra is an open source tool that enables you to test applications that use Cassandra in a quick, deterministic way.

It is especially aimed edge case testing such as read and write timeouts.

It acts as a real Cassandra instance and can be primed to respond with results or with exceptions like read timeouts. It does this by implementing the server side of the CQL binary protocol.

It is separated into two components:

Scassandra, currently v1.1.0, is aimed at Java developers so most of the information is on the Java Client section of the website. It also may be used as a standalone jar.

Release v1.1.1

Release v1.1.0

Release v1.0.10

Release v1.0.9

Release v1.0.8

Release v1.0.7

Release v1.0.6

Release v1.0.5

Release v1.0.4

Release v1.0.3

Release v1.0.2

Release v1.0.1

Release v1.0.0

Release v0.11.0

Release v0.10.0

Release v0.9.1

Release v0.8.0

Release v0.7.0

Release v0.6.0

Release v0.5.0

Release v0.4.1

Release v0.3.0

Release v0.2.0

Release v0.1

Feature backlog

For feature requests and bug reports raise an issue at the Github issues page

Any questions ping me on twitter: @chbatey

","id":"f25dfc52-d2f5-5804-8a88-de850ba485a3","title":"Stubbed Cassandra","origin_url":"http://www.scassandra.org/","url":"http://www.scassandra.org/","wallabag_created_at":"2018-10-08T20:04:55+00:00","published_at":null,"published_by":null,"reading_time":4,"domain_name":"www.scassandra.org","preview_picture":null,"tags":["cassandra","testing"],"description":"Developing software is fun. Developing software that is well tested, where those tests run quickly is even more fun.Stubbed Cassandra is an open source tool that enables you to test applications that ..."},{"content":"

Support: \"Join
Documentation: User Guide, JavaDocs\n
A/B Testing Overview: \"A/B \"Blog \"Blog
Continuous Integration: \"Build\n\"Coverage\n\"Maven
License: \"Apache

Project

Wasabi A/B Testing Service is a real-time, enterprise-grade, 100% API driven project. Users are empowered to own their own data, and run experiments across web, mobile, and desktop. It’s fast, easy to use, it’s chock full of features, and instrumentation is minimal.

Learn more about how Wasabi can empower your team to move from hunches to actionable, data-driven user insights with our simple, flexible, and scalable experimentation platform.

Features

User Interface

Get Started

The following steps will help you install the needed tools, then build and run a complete Wasabi stack.

Bootstrap Your Environment

Mac OS
% /usr/bin/ruby \\\n  -e \"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)\"\n% brew install git\n% git clone https://github.com/intuit/wasabi.git\n% cd wasabi\n% ./bin/wasabi.sh bootstrap

Installed tools include: homebrew 0.9, git 2,\nmaven 3, java 1.8,\ndocker 1.12, node 6 and python 2.7.

Ubuntu

Bootstrapping on Ubuntu requires sudo privileges to install all the required dependencies. You will be prompted to enter your password. Currently only 16.04 (x64) is supported.

% sudo apt-get install git\n% git clone https://github.com/intuit/wasabi.git\n% cd wasabi\n% ./bin/wasabi.sh bootstrap\n% sudo reboot

NOTE: A reboot is required after running the bootstrap command on Ubuntu.

For all other processes (build, start etc.) the commands are same for Ubuntu and Mac OS.

Installed tools include: git 2,\nmaven 3, OpenJdk 8,\ndocker 1.12, node 6 and python 2.7

Similar tooling will work for Windows. Contribute a patch :)

Start Wasabi

Now that we have the necessary tools in place, let's move on to build and start Wasabi, followed by issuing a ping\ncommand to verify the build:

% ./bin/wasabi.sh build start\n...\nwasabi is operational:\n  ui: % open http://localhost:8080     note: sign in as admin/admin\n  ping: % curl -i http://localhost:8080/api/v1/ping\n  debug: attach to localhost:8180\n% curl -i http://localhost:8080/api/v1/ping\nHTTP/1.1 200 OK\nDate: Wed, 25 May 2016 00:25:47 GMT\n...\nX-Application-Id: wasabi-api-20151215171929-SNAPSHOT-development\nContent-Type: application/json\nTransfer-Encoding: chunked\nServer: Jetty(9.3.z-SNAPSHOT)\n{\n  \"componentHealths\":[\n    {\n      \"componentName\":\"Experiments Cassandra\",\n      \"healthy\":true\n    },\n    {\n      \"componentName\":\"MySql\",\"healthy\":true\n    }\n  ],\n  \"wasabiVersion\":\"wasabi-api-20151215171929-SNAPSHOT-development\"\n}

Congratulations! You are the proud owner of a newly minted Wasabi instance. :)

Running Wasabi with remote storage

Set Mysql and Cassandra credentials
Download Cassandra migration tool https://oss.sonatype.org/content/repositories/public/com/builtamont/cassandra-migration/0.9/cassandra-migration-0.9-jar-with-dependencies.jar
Set up your environment variables
export CASSANDRA_MIGRATION=/location/of/cassandra-migration-0.9-jar-with-dependencies.jar
export MIGRATION_SCRIPT=/location/of/modules/repository-datastax/src/main/resources/com/intuit/wasabi/repository/impl/cassandra/migration
Set up Cassandra tables
CQLSH_VERSION=<version> CQLSH_USERNAME=<username> CQLSH_PASSWORD=<pwd> CQLSH_HOST=<host> bin/docker/migration.sh
Run Wasabi with env variables for remote storage hosts
MYSQL_HOST=<mysql_host> NODE_HOST=<cassandra_host> ./bin/wasabi.sh start:wasabi
Run Wasabi outside of docker with WASABI_CONFIGURATION for remote storage hosts
WASABI_CONFIGURATION=\"\n  -Ddatabase.url.host=$MYSQL_HOST\\\n  -Ddatabase.url.port=$MYSQL_PORT\\\n  -Ddatabase.url.dbname=$MYSQL_DATABASE\\\n  -Ddatabase.user=$MYSQL_USER\\\n  -Ddatabase.password=$MYSQL_PASSWORD\\\n  -Ddatabase.pool.connections.min=$MYSQL_MIN_CONNECTIONS\\\n  -Ddatabase.pool.connections.max=$MYSQL_MAX_CONNECTIONS\\\n  -Dusername=$CASSANDRA_USER\\\n  -Dpassword=$CASSANDRA_PASSWORD\\\n  -DnodeHosts=$CASSANDRA_HOST\\\n  -DtokenAwareLoadBalancingLocalDC=$CASSANDRA_DATACENTER\\\n  -Dapplication.http.port=$PORT\" bash usr/local/wasabi-main-*/bin/run

Troubleshooting

% ./bin/wasabi.sh status\nCONTAINER ID        IMAGE                    COMMAND                  CREATED             STATUS              PORTS                                                                     NAMES\n8c12458057ef        wasabi-main              \"entrypoint.sh wasabi\"   25 minutes ago      Up 25 minutes       0.0.0.0:8080->8080/tcp, 0.0.0.0:8090->8090/tcp, 0.0.0.0:8180->8180/tcp    wasabi-main\n979ecc885239        mysql:5.6                \"docker-entrypoint.sh\"   26 minutes ago      Up 26 minutes       0.0.0.0:3306->3306/tcp                                                    wasabi-mysql\n2d33a96abdcb        cassandra:2.1            \"/docker-entrypoint.s\"   27 minutes ago      Up 27 minutes       7000-7001/tcp, 0.0.0.0:9042->9042/tcp, 7199/tcp, 0.0.0.0:9160->9160/tcp   wasabi-cassandra
% ./bin/wasabi.sh start:cassandra\n% ./bin/wasabi.sh start:wasabi

Call Wasabi

These are the 3 common REST endpoints that you will use to instrument your client application with Wasabi.

Let's assume that you've created and started an experiment, 'BuyButton,' in the 'Demo_App' application with the following buckets:

You can assign a user with a unique ID (e.g. 'userID1') to the experiment by making this HTTP request:

\n

Assign a user to experiment and bucket:

\n
% curl -H \"Content-Type: application/json\" \\\n    http://localhost:8080/api/v1/assignments/applications/Demo_App/experiments/BuyButton/users/userID1\n{  \n   \"cache\":true,\n   \"payload\":\"green\",\n   \"assignment\":\"BucketA\",\n   \"context\":\"PROD\",\n   \"status\":\"NEW_ASSIGNMENT\"\n}

Now the 'userID1' user is assigned into the 'BucketA' bucket. Let's further record an impression, meaning the user has seen a given experience:

\n

Record an impression:

\n
% curl -H \"Content-Type: application/json\" \\\n    -d \"{\\\"events\\\":[{\\\"name\\\":\\\"IMPRESSION\\\"}]}\" \\\n    http://localhost:8080/api/v1/events/applications/Demo_App/experiments/BuyButton/users/userID1

If the 'userID1' user performs an action such as clicking the Buy button, you'd record that action with the following request:

\n

Record an action:

\n
% curl -H \"Content-Type: application/json\" \\\n    -d \"{\\\"events\\\":[{\\\"name\\\":\\\"BuyClicked\\\"}]}\" \\\n    http://localhost:8080/api/v1/events/applications/Demo_App/experiments/BuyButton/users/userID1

Explore Various Resources

The following developer resources are available:

\n

API: Swagger API playground

\n
% ./bin/wasabi.sh resource:api
\n

Javadoc

\n
% ./bin/wasabi.sh resource:doc
\n

Wasabi UI

\n
% ./bin/wasabi.sh resource:ui
\n

Cassandra: cqlsh shell

\n
% ./bin/wasabi.sh resource:cassandra
\n

MySQL: mysql shell

\n
% ./bin/wasabi.sh resource:mysql
\n

Java Debugger: Remote attach configuration

\n
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8180

Stop Wasabi

Alas, all good things must come to an end. Let's clean things up a bit stop the newly created Wasabi stack:

At this point in time, we now have all the requisite tools installed, and subsequent invocations of Wasabi will\nstart up much more quickly.

% ./bin/wasabi.sh stop

Get Familiar with wasabi.sh

Further, there are a number of additional wasabi.sh options available you should become familiar with:

% ./bin/wasabi.sh --help\n  usage: wasabi.sh [options] [commands]\n  options:\n    -e | --endpoint [ host:port ]          : api endpoint; default: localhost:8080\n    -v | --verify [ true | false ]         : verify installation configuration; default: false\n    -s | --sleep [ sleep-time ]            : sleep/wait time in seconds; default: 30\n    -h | --help                            : help message\n  commands:\n    bootstrap                              : install dependencies\n    build                                  : build project\n    start[:cassandra,mysql,wasabi]         : start all, cassandra, mysql, wasabi\n    test                                   : test wasabi\n    stop[:wasabi,cassandra,mysql]          : stop all, wasabi, cassandra, mysql\n    resource[:ui,api,doc,cassandra,mysql]  : open resource api, javadoc, cassandra, mysql\n    status                                 : display resource status\n    remove[:wasabi,cassandra,mysql]        : remove all, wasabi, cassandra, mysql\n    package                                : build deployable packages\n    release[:start,finish]                 : promote release

Develop

Build and Run Wasabi Server

% mvn package\n% ./bin/wasabi.sh start:cassandra,mysql\n% (cd modules/main/target; \\\n    WASABI_CONFIGURATION=\"-DnodeHosts=localhost -Ddatabase.url.host=localhost\" ./wasabi-main-*-SNAPSHOT-development/bin/run) &\n% curl -i http://localhost:8080/api/v1/ping\n...

The runtime logs can be accessed executing the following command in a another shell:

\n

Viewing runtime logs:

\n
% tail -f modules/main/target/wasabi-main-*-SNAPSHOT-development/logs/wasabi-main-*-SNAPSHOT-development.log

Build and Run Wasabi UI

% cd modules/ui\n% grunt build
% grunt serve

Stop Wasabi

% ./bin/wasabi.sh stop

Now while that was fun, in all likelihood you will be using an IDE to work on Wasabi. In doing so, you need only\nadd the configuration information above to the JVM commandline prior to startup:

\n

Wasabi runtime configuration:

\n
-DnodeHosts=localhost -Ddatabase.url.host=localhost

Run Integration Tests

Code changes can readily be verified by running the growing collection of included integration tests:

% ./bin/wasabi.sh start test stop
Troubleshooting

Integration tests might fail intermittently due to a time drift issue in docker containers on Mac OSX.

When the Mac sleeps and wakes back up, there is a lag created between the clock in the Mac vs the\nrunning docker containers. This is a known issue in Docker for Mac.

This can be fixed by running the following command:

% docker run --rm --privileged alpine hwclock -s

The above command will need to be run every time when there is a time drift.

To automatically run this command and update the time each time the Mac wakes up, you could install\nthe following agent:

% curl https://raw.githubusercontent.com/arunvelsriram/docker-time-sync-agent/master/install.sh | bash

You can read more about this at: quick-tip-fixing-time-drift-issue-on-docker-for-mac

Package and Deploy at Scale

Wasabi can readily be packaged as installable rpm or deb distributions and deployed at scale as follows:

\n

Package by running integration tests 1st:

\n
% ./bin/wasabi.sh start package
\n

Package without integration tests, if needed:

\n
% ./bin/wasabi.sh -t false package
\n

Find generated package files:

\n
% find . -type f \\( -name \"*.rpm\" -or -name \"*.deb\" \\)

Note: Java 8 is a runtime dependency

Integrate

Wasabi is readily embeddable via the following maven dependency GAV family:

<dependency>\n    <groupId>com.intuit.wasabi</groupId>\n    <artifactId>wasabi</artifactId>\n    <version>1.0.20160627213750<build_timestamp></version>\n</dependency>

Contribute

We greatly encourage contributions! You can add new features, report and fix existing bugs, write docs and\ntutorials, or any of the above. Feel free to open issues and/or send pull requests.

The master branch of this repository contains the latest stable release of Wasabi, while snapshots are published to the develop branch. In general, pull requests should be submitted against develop by forking this repo into your account, developing and testing your changes, and creating pull requests to request merges. See the Contributing to a Project\narticle for more details about how to contribute in general and find more specific information on how to write code for Wasabi in our user guide.

Extension projects such as browser plugins, client integration libraries, and apps can be contributed under the contrib directory.

Steps to contribute:

  1. Fork this repository into your account on Github
    2. \n
  2. Clone your forked repository (not our original one) to your hard drive with git clone https://github.com/YOURUSERNAME/wasabi.git
    3. \n
  3. Design and develop your changes
    4. \n
  4. Add/update unit tests
    5. \n
  5. Add/update integration tests
    6. \n
  6. Add/update documentation on gh-pages branch
    7. \n
  7. Create a pull request for review to request merge
    8. \n
  8. Obtain 2 approval squirrels before your changes can be merged
    9. \n

Thank you for your contribution!

","id":"965b9cd4-097c-560f-94b6-00ce67a88391","title":"intuit/wasabi","origin_url":"https://github.com/intuit/wasabi","url":"https://github.com/intuit/wasabi","wallabag_created_at":"2018-09-24T16:18:17+00:00","published_at":null,"published_by":"['']","reading_time":10,"domain_name":"github.com","preview_picture":"https://opengraph.githubassets.com/6b71518933139be280b839b74b254bf883d8ad401517eabea88c5f1d20fc4cc9/intuit/wasabi","tags":["open.source","cassandra","testing"],"description":"Support: Documentation: User Guide, JavaDocs\nA/B Testing Overview: Continuous Integration: \n\n License: ProjectWasabi A/B Testing Service is a real-time, enterprise-grade, 100% API driven project...."},{"content":"

In the previous two posts of this series (Part 1 and Part 2) I covered some of the basic commands of cassandra-stress. In this post I will start looking at the use of the stress YAML file for more advanced stress scenarios, particularly where you want to run stress against a schema that matches one you are planning to use for your application.

It’s worth noting in the intro that cassandra-stress with a YAML file use a significantly (80%?) different set of code to the standard read/write/mixed commands. So, some assumptions and learnings from the standard commands won’t hold for YAML-driven stress. To cite one example, when running based on YAML, cassandra-stress does not validate that data returned from a select has the expected values as it does with read or mixed.

For this article, I’ll reference the following YAML specification file:

Before explaining the contents here, let’s see what happens when we run it with the following simple scenario:
cassandra-stress user profile=file:///eg-files/stressprofilemixed.yaml no-warmup ops(insert=1) n=100 -rate threads=1 -node x.x.x.x

After running this on an empty cluster, I ran select count(*) from eventsrawtest;. The result? 345 rows – probably not you would have guessed. Here’s how cassandra-stress gets to that:

Let’s look at some of the other column settings:
We covered most of the insert settings in the introductory points but here’s a recap:
The final section the yaml file that bears some explanation is the queries section. For each query, you specify:
The ops command specified as part of the command line controls the mix of different operations to run. Take for example the following command:

cassandra-stress user profile=file:///eg-files/stressprofilemixed.yaml ops(insert=1, pull_for_rollup=1, get-value=10) n=120 -node x.x.x.x

This will execute insert batches, pull_for_rollup queries and get-value queries in the ratio 1:1:10. So for this specific example, we’d get 10 inserts, 10 pull_for_rollup queries and 100 get-value queries.

Hopefully that’s explained the key information you need to use a YAML profile for running cassandra stress. In future instalments I’ll take a look at some of the remaining command line options and walk through a full end-to-end example of designing and executing a test.

Click here for Part One: Deep Diving into Cassandra Stress
Click here for Part Two: Mixed Command

","id":"d7cce620-feeb-572c-bc3f-3a4fd803fdf6","title":"Deep Diving cassandra-stress - Part 3 (Using YAML Profiles) - Instaclustr","origin_url":"https://www.instaclustr.com/deep-diving-cassandra-stress-part-3-using-yaml-profiles/","url":"https://www.instaclustr.com/deep-diving-cassandra-stress-part-3-using-yaml-profiles/","wallabag_created_at":"2018-09-13T14:57:14+00:00","published_at":"2016-08-24T05:03:19+00:00","published_by":"['']","reading_time":5,"domain_name":"www.instaclustr.com","preview_picture":"https://www.instaclustr.com/wp-content/uploads/2021/10/cs-article3.png","tags":["stress","cassandra","cassandra.stress","testing"],"description":"In the previous two posts of this series (Part 1 and Part 2) I covered some of the basic commands of cassandra-stress. In this post I will start looking at the use of the stress YAML file for more adv..."}],"skip":0,"limit":8,"totalCount":12,"currentPage":1,"url":"/tags/testing"}},"staticQueryHashes":[]}