4. Implementation and Requirements
4.2 Requirements
The project will be using SOAP messages for request/response data between client and the server. The request will be send to the load balancer algorithm running on tomcat, which will find out which will try to find out which server is behaving best at the moment, and will forward the request to that server, which will respond back with the output. In total 3 web services will be developed. The first two web services developed are for the load balancer algorithm, and third web service is for the program, which will return the output back to client. Both load balancer web service will be calling third program web service for the output responded back to the client.
4.2 Requirements
4.2.1 Hardware
The system hardware used for the implementation will be my local machine, which has windows and Linux both configured. The hardware details are as follow:
• Windows 7, i5 processor
• Linux Env
• 4Gb RAM, 64 bit Operating System
• Amazon Cloud 4.2.2 Software
• Tomcat 6
• Java 1.6
• Web Service will be built using JAX-‐WS 3.0 API on Java1.6.
• SoapUI client will be used to access the web service.
• Eclipse IDE will be used for development purposes.
• Load balancing algorithms will be developed using Java 1.6.
• Amazon EC2 virtual instances will be created [12].
• Jars will be downloaded.
• UTF-‐8 Encoding will be used.
• Spring 3.0
• HP Load Runner Tool
4.2.3 Metrics
The core of any comparison study is metrics. Several studies have used different metrics (such as performance, storage etc.) to evaluate and compare different services [7] [8] [9]. The project will consider metrics, which are relevant for this
comparison. The various parameters that can be considered are the performance, response time, scalability, throughput, and resource utilization. Analysis will be based on 99%tile of all the response time, along with maximum time, minimum time and average time too. Standard deviation will also be measured for both the
algorithms. Various types of strategies like variance, thread, simple etc. will be used.
4.2.3.1 Round Trip Time
The end-‐to-‐end response time will be compared between the two load balancers by sending requests through the web service. For good load balancer, end-‐to-‐end response time should be as low as possible. The Response time will be measured against the load sent on two load balancers.
4.2.3.2 Memory Utilization
Memory utilization will be compared for the load balancers against the load.
Memory utilization can be measured through JVM. To determine whether load balancer is better, it should be consuming less memory, and should do garbage collection at timely manner to remove all unused object. It should not do memory leak.
4.2.3.3 Cost
Cost for utilizing different cloud services will be estimated as its one of the main deciding factor for the enterprises. The cost serves as one of the main deciding factor because enterprise has budget constraints, and they have to look at the best available option, which will be beneficial for the industry.
4.2.3.4 Scalability
This is an ability of an algorithm to perform load balancing with any finite number of nodes. The scalability will be tested against the load balancer algorithm by increasing the number of nodes, or number of transactions per second to check what the upper limit is till the system starts degrading. The higher the scalable factor, better the performance is.
4.2.3.5 TPS
It stands for “transaction made per second”. For example: a test case that runs for 10 seconds and handled 100 requests will get tps of 10. Algorithm, which provides higher “tps”, is considered better. [18]
4.2.3.6 BPS
It stands for “bytes per second”. For example: test case running for 10 seconds and handled 100000 bytes will get BPS of 10000. Algorithm, which provides higher
“bps”, is considered better. [18]
These parameters will be compared with the data set that will be passed to the URL’s where the load balancer is installed which will further send the requests to the web service and get the data back.
Data set will be in form of soap requests. We will increase the number of thread count of the soap request in order to overload the server. The data set will be of the format:
Figure 6: Soap Request
The SOAP request will be sent through SOAPUI, and we will be using SOAP UI Load Test tool [15] to get the metrics we have to compare. The metrics will be compared against the parameters “bps”, “tps”, “avg time (rtt),” memory utilization”.
Different Load strategies will be used for each parameter for evaluating the
response from the load balancer. The strategies are simple, variance, burst, thread, grid [15].
4.2.3.7 Simple Strategy
This strategy runs by adding definite amount of thread with a definite delay between each thread run for server. For example for a test to run with test with 5 threads with 5 seconds delay, we initialize thread array to 5, delay to 5000ms. [18]
4.2.3.8 Variance Strategy
This strategy fluctuate the thread amount over a course of duration in a
“sawtooth” manor; we set interval to the desired value and the variance value which determines how much thread amount should decrease or increase during the test duration. [18]
4.2.3.9 Thread Strategy
This test increases the amount of thread from one level to another over the run test duration. The main purpose of this strategy is to find at which thread count the test can attain the highest transaction per second, and it can also be used to find the level of thread count where the performance starts degrading. [18]