Performance test scenarios

TEST CONFIGURATION: As was agrred during meeting we need two configurations to perform tests on: the weaker and the stronger one. The weaker one is the one we currently use, it has 1 master and 1 worker. The new machine should have 1 master and 3 workers.

These tests should measure time in which DB responds to queries in order to check if our solution is viable in Big Data scenarios. The results should be then used to generate graph.

Test scenarios are based on: http://docs.aws.amazon.com/ElasticMapReduce/latest/DeveloperGuide/impala-optimization.html

Some simple test cases:

TEST 1: "Keyword test" This is about measuring sprak processing delay.For the sake of test, we define sprak processing delay as the time between insertion off new keyword into database and the time that first statistics for this keyword appear in database. The test should be performed in relation to number of keywords that are sought for. We would like to see how the delay changes with count of examined keywords. Based on this mesurement we can test how many keywords we can look for, before the delay becomes unberable We should test how many keywords we can search for: a) start with some small amount (for example 5) b) add with each iteration 5 more The amount given above is example and should be changed if we find out that it's too big/small for test scenario.
By testing on two sprak clusters 1+1 and 1+3, we would like to see how much of the discovered relation depends on the cluster performance, and how much on the implementation itself We think that in this test there is no need to manipulate performance of database vm, because the database shouldn't be the bottelneck here

TEST 2: "Aggregation test" The aggregation test uses a query that scans a single table, groups the rows, and calculates the size of each group. Measure the time in which DB returns the results. The test should be performed on UserKeywordUsage. This test should be performed in relation to number of records in UserKeywordUsage as this should have the most impact on query time. Initial database test show that database is stresed minimally, mysqld processors usage stays under 10% and memory usage stays under 4%, this means we may run much more test on curretn database without hitting the hardware limit

TEST 3: "Join test" Perform a join on few example tables (UserActivity and UserKeyWordUsage?). Measure the time needed by DB to respond to query.