SE401:Group33:Testing
Our framework should:
- Scale a web service to provide a consistent quality of service
- Balance the load across all available instances.
We will run a set of tests to measure how quickly our web service can scale up with an increase in requests and whether or not proactively scheduling scaling is of any real benefit.
- (HAProxy comparison)
- (shutdown time)
- Sessions vs no sessions (at the moment balancing is only done by permanent redirrect so only the initial request is balanced. The load balancing will be extended to allow a connection to be rebalanced if the server it is using becomes unavailable.(like a dns list??))
- load measurement metrics (different measurements and different scaling thresholds).
Informal Testing
First set of tests will be on the lab machines to prove that the control module works and that the load balancing reaches each server. This well then give us some confidence to run tests on amazon machines.
Load Balancing
We can make a web page with the machine address encoded in and browse to the controller and see that requests are indeed redirected to different machines. This will not necessarily prove that the load is balanced equally and this will be done with logging load over time and stressing the instances with JMeter on the local machines. These load values for different machines can be compared over time for a visual test of balancing.
Scaling
Initial lab tests will use a LabInstanceController which will not actually start and stop additional machines. Instead it will give output stateing when it wants to start additional instances and when it wants to stop them. If the behaviour appears to be correct, we can continue on to formal testing.
Control Module
To prove that the control adapts to crashes or communication failure, we will physically stop processes and check that the remaining processes adapt by re-electing a leader.
PeerWise
Simple survey-like web based application that makes use of a database.
Test 1:
PeerWise will be deployed on instance. This should be in the state where hidra quietly monitors traffic. JMeter will be deployed on a set of separate machine instances and will attept to stress the instance (settings will be gathered from tests in the lab). Each instance will log their own load values to an S3 bucket. We measure the downtime associated with going from 1-3 instances and then for each additional instance.
Test #
JMeter
The JMeter tests will be session orientated with a login, creation of a survey, completion of a survey and a logout.
Busy Wait
We will make a simple web service with a busy wait to simulate a CPU intensive web service.
- Compare scaling modules
- Compare scaling threshold values