Server Load Balancer Test Methodology

Rethink Server Load Balancer Testing

A methodology to measure the performance, security, and stability of server load balancers under
real-world network conditions

www.breakingpoint.com
© 2005 - 2010. BreakingPoint Systems, Inc. All rights reserved. The BreakingPoint logo is a trademark of BreakingPoint Systems, Inc. 1
All other trademarks are the property of their respective owners.


Table of Contents
Introduction .................................................................................................................................................................................................................... 3

Layer 4 Top TC ................................................................................................................................................................................................................ 5

HTTP Load Balancer Test............................................................................................................................................................................................. 26

HTTPS/SSL ....................................................................................................................................................................................................................... 52

HTTP Caching ................................................................................................................................................................................................................. 74

Dual Traffic HTTP and IMAP ....................................................................................................................................................................................... 96

BlockFuzzer ..................................................................................................................................................................................................................... 127

Load Balancer Configuration .................................................................................................................................................................................... 135

About BreakingPoint ................................................................................................................................................................................................... 137



Introduction
Today’s network is under higher demand than ever before, each day handling ever growing and more complex business and Web
applications. A single server will not be able to handle the load demand required; multiple servers are needed and must be used to
meet the demand. For ease of use, a single IP address or domain name must be used; however, if several servers are required, this adds
complexity. Using a load balancer can ease the complexity of the network setup.

With the continued development of web applications, virtualization, cloud computing and more, a load balancer has become an integral
piece of networking equipment. With the use of a load balancer, a single service can be provided from multiple servers. A load balancer runs
on Layers 4 through 7 of the OSI Model, and some of the common protocols that are usually load balanced are HTTP, IRC, FTP, NNTP and
DNS. When in use, a load balancer is placed in front of a server farm on the network. The load balancer listens on the needed port, and when
a request comes in for the service, the load balancer will forward the request to one of the available servers. When the back-end server
receives the request from the load balancer, it will respond to the load balancer. In turn, the load balancer will respond to the client that
made the initial request. This makes the load balancer an invisible piece of networking equipment to the client.

Load balancers are aware of the requested protocol and will forward the connection to the correct server. Since not every server will be on
equal hardware or be able to handle equal loads, load balancers can be configured with an assigned weight for each server. For example,
a single core server can be configured with a lower weight than a quad core server because the quad core server will be able to handle a
higher offered load. This ensures that each client will receive the same experience as the next.

Another added benefit of using a load balancer is it helps maintain uptime of the requested services. If one server fails or is taken down for
an upgrade, the remaining servers are able to maintain and handle the load until the downed server is online again.

Not all load balancers are created equal. Some have more features than others, but a set of common features does exist between them.
As expected, load balancers support all TCP and UDP protocols. A form of SSL acceleration is usually available to improve the speed of
encryption. Another common feature is content caching: The load balancer will store objects that are frequently used. When this object is
requested, the load balancer will speed up the process by sending the object instead of asking a server for it. Other common features that
load balancers support are content compression, session persistence and bandwidth management.

The following Resiliency Methodology will demonstrate how to configure a load balancer and set up the BreakingPoint Storm CTM. This
Resiliency Methodology contains five different measurements and each are given a brief outline below.

Test 1: Layer 4 TCP
This test will determine the number of TCP connections per second that the load balancer is able to handle. Also, the TCP setup
time will be analyzed to determine how a greater number of TCP connections per second affects the time it takes to establish the TCP
connection. This test is also a baseline measurement for tests 2-5.

Test 2: HTTP
This test will determine the number of HTTP connections per second the load balancer is able to handle. Also, the BreakingPoint
Storm CTM will be configured to serve out five different sized HTTP pages. The overall bandwidth that the load balancer is able to support
will be determined.

Test 3: HTTPS
This is the same test as the HTTP , except encryption will be used. Normally, the HTTPS connection is made with the load balancer, and
the connection between the load balancer and the server is not encrypted, taking away the overhead of encryption.



Test 4: HTTP Caching
As load balancers are able to locally cache objects, the BreakingPoint Storm CTM will be configured to send out dynamic pages and
image files. The TCP connection setup time will be analyzed to make sure the load balancer is locally caching the needed files.

Test 5: Dual Traffic HTTP and IMAP
Load balancers are able to handle multiple protocols at a time. The BreakingPoint Storm CTM will be configured to use both HTTP
and IMAP protocols. This helps determine the load balancer’s ability to handle multiple protocols while being stressed. Data rates and TCP
setup times are a couple of the results analyzed at the end of the test.

Test 6: Fuzzer
This test is an add-on test to the previous ones. This test will ensure that the load balancer is able to handle malformed packets or errors
within the packet. Results will be examined to determine the load balancer’s ability.



Layer 4 Top TC
RFC:
• RFC 793 – Transmission Control Protocol

Overview:
A basic Layer 4 TCP measurement will be performed. The load balancer should be configured with an open port of 80, as this is the port that
will be used during the test. The load balancer also should be configured with a range of IP Addresses that amounts to about 5% of the total
supported back-end servers to act as the end points for the TCP measurement. The BreakingPoint Storm CTM will act as both the clients
and the servers during the measurement. The BreakingPoint Storm CTM will be configured to use the Session Sender test component to
generate and receive the TCP requests.

Objective:
Determine the maximum number of TCP connections per second a load balancer is able to handle before dropping requests.

Setup:



1. Open your favorite Web browser and connect to the BreakingPoint Storm CTM. Once the page has loaded, select Start
BreakingPoint Systems Control Center.

2. Log into the BreakingPoint Storm CTM by entering your Login ID and Password. Once done, click the Login button.



3. Reserve the required ports to run the test.

4. Next, select Test  New Test to start with configuring the test.



5. Select the first item from the list, Select the DUT/Network located in the Test Quick Steps.

6. Select Open network neighborhood screen to create a Network Neighborhood for the test.



7. Select the Create a new Network Neighborhood (‘+’) button.

8. Enter an easy-to-recall name for the new Network Neighborhood and click OK.



9. Notice the interface list at the top of the screen. It lists Interfaces 1-4 and an External; only two interfaces and the
external are required for this test. Delete Interface 3 and Interface 4 by selecting the interface and then clicking
the close button that appears on the tab. When prompted about the removal of the interface, select Yes.



10. Configure all the required IP information for Interface 1. Once all the IP information has been entered, click the Apply
Changes button and then the Save Network button.

11. Select the Interface 2 tab and again configure all the required IP information, making sure to change the Type from

button.
Virtual Router to Host. Once the configuration has been completed, click Apply Changes and the Save Network



12. Select the External tab. An entry is already present in the Subnet section. Delete this entry by selecting the trash can
button.

13. Once the entry is deleted, a new entry must be created. Enter in the IP address information in the Minimum IP
Address and Maximum IP Address fields. Click the Add Range button once completed. Again, click the Save
Network button.



14. Select the Return to Previous Screen button.

15. Under Device Under Test(s), verify that BreakingPoint Default is selected, and under Network Neighborhood(s)
verify that the newly created one is selected. Click Accept once completed.

16. When prompted about switching Network Neighborhoods because the current one has more interfaces select Yes.



17. Select Add a Test Component from Test Quick Steps.

18. Select Session Sender (L4) from the Select a component type window.



19. We will now perform step 3 of the Test Quick Steps. Rename the component from Session Sender to TCP Sessions.
Verify that the Active checkbox is selected. Click Apply Changes once completed.

20. Select the Interfaces tab. Verify that the External Server checkbox is selected. For Interface 1, verify that the Client
checkbox is selected, and for Interface 2 verify that the Server checkbox is selected. Click Apply Changes once
completed.

21. Select the Parameters tab. This is where all the test criteria will be defined and configured for this test.



22. Not every parameter will be changed. The first one that should be changed is TCP Session Duration (segments).
Change the value from 20 to 0. This will allow for a higher rate of TCP connections per second to be established. Click
Apply Changes once completed.

23. The next parameter that needs to be changed is the Minimum data rate. It is currently set to 200 and needs to be
changed to 1000. This value is in Megabits/second. Again, click Apply Changes once completed.

24. The next parameter that needs to be changed is the Port distribution type under Destination Port. Use the drop
down menu and change the value to Constant. Also, change the Minimum port number from 6 to 80 (or a known
open port on your load balancer). Click Apply Changes once completed.



25. Under Session Ramp Distribution, change the Ramp Up Behavior from Full Open to Full Open + Data + Close.
For Ramp Up Seconds, enter a value of 148010. This is a calculated value; we wish to attempt to connect 750,000
TCP connections/second. Initially, 10,000 connections will be established, and then another 50 every 10 seconds
thereafter. We add 10 seconds for the initial 10,000 TCP connections. As a mathematical expression it would look like
this: ((((750000-10000)/50) * 10)+ 10. We must make sure the Ramp Up Seconds is a long enough period of time
to complete this process. Provide 30 seconds for the Ramp Down period. You will have to scroll down for this field.
Click Apply Changes.

26. Scroll down to the Ramp Up Profile. Use the Ramp Up Profile Type drop down menu and change the value to

test. Enter a value of 10000. As we wish to determine the maximum number of TCP connections that are possible
Stair Step. The Minimum Connection Rate is the number of TCP connections that will be used at the start of the

per second enter a value of 750000 in the Maximum Connection Rate. Enter a value of 50 for the Increment N

attempts every 10 seconds. This value can be increased for a shorter test, but the results might not be as accurate.
connections per second and enter a value of 10 for Every N seconds. This will add an additional 50 TCP connection

Please note, you will need to scroll down to locate some of these fields. Click Apply Changes once completed.



27. Under Session Configuration, set both Maximum Simultaneous Sessions and Maximum Sessions Per Second to
their maximum values. Click Apply Changes once completed.

28. No other parameters need to be configured. Make sure the Test Status has a green check mark next to it. If there is
not, determine what is wrong by selecting Test Status and viewing the errors.

29. Before we select Save and Run from Test Quick Steps, edit the Test Information Description.



30. Select Save and Run from Test Quick Steps.

31. If the test has not previously been saved, enter a name for the test and click Save.



32. While the test is running, select the TCP tab.

33. Once the test has completed running, verify that it successfully passed. Click Close.



34. In the lower left corner of the Real Time Statistics window, select the graph button to view detailed results. This will
open the results in a new browser window.

35. Go to the browser. On the left side is the navigation panel, where you can navigate and browse the results. The results
and test information will be displayed on the right side of the browser.

36. Expand the Test Results for TCP Sessions folder, and then expand the Details folder. Select TCP Connection Rate.



37. Once TCP Connection Rate has been selected, a graph will display the Client and Server attempt rate, establish rate
and close rate. Also, a table is displayed showing the values used to create the graph.



38. Using the table, it is possible to determine the maximum TCP Connection Rate. From the Client establish rate (TCP
Sessions/s) column, locate the highest value. Using the graph, find the highest Client establish rate to determine
the time the highest Client establish rate happened. With the DUT used in this test, it looks like it happened at about
11,270 seconds with a rate of 75,237.9 TCP Sessions/s.



39. Another interesting metric is the TCP Response Time. Select the TCP Response Time in the navigational panel. This
graph shows the time it took for a TCP response to be made. The quicker the response times, the better.

40. Select TCP Concurrent Connections under the Detail folder. A graph and a table of the results will be displayed. The
graph is based on the results found in the table. They both provide a value for the number of Client concurrent TCP
sessions.



41. Another interesting metric that can be viewed is the Frame Data Rate. Again, this is under the Detail folder. The
Frame Data Rate will show the data transmit rate and the data receive rate that occurred throughout the test.

This test is just a starting point. Other more complex Layer 4 tests are possible. The following are some examples:

• Maximum TCP Open Rate (full open of clients, do not close client connections)
• Maximum TCP with Opening and Closing clients at same time.
• Throughput tests with varying number of clients.
• Increased number of supported back-end servers to 10%, 25%, 50%, 75% and 100%.



HTTP Load Balancer Test
RFC:
• RFC 1945 – Hypertext Transfer Protocol – HTTP/1.0

Overview:
The BreakingPoint Storm CTM will simulate the HTTP protocol. The BreakingPoint Storm CTM will simulate both the client and the server.
The server will respond with different page sizes to help mimic a more realistic Web browsing session. The load balancer will distribute the
connections to the simulated Web servers, and we can determine the number of connections per second possible with the configuration of
the load balancer.

Objective:
Determine the number of HTTP connections per second possible.

Setup:



1. Open your favorite Web browser and connect to the BreakingPoint Storm CTM. Once the page has loaded, select Start
BreakingPoint Systems Control Center.

2. Log into the BreakingPoint device by entering your Login ID and Password. Once done, select the Login button.




4. Next, select Test  New Test to start with configuring the test.



5. To configure the test, we will use the Test Quick Steps. Select Select the DUT/Network from the list.

6. In the previous test, we created a Network Neighborhood; since the test setup has not changed, it is possible to reuse
that Network Neighborhood. Select BreakingPoint Default as the Device Under Test(s) and the previously created
Network Neighborhood. Click Accept once completed.



7. Using the Test Quick Steps, select Add a Test Component.

8. Select Application Simulator (L7) as the component type. Click Close once selected.



9. Under the Information tab, enter a name for the Application Simulator component and Click Apply Changes.

10. Select the Interfaces tab. Enable the External Server and make sure Interface 1 is set as a Client and Interface 2 is
set as a Server. Once completed click Apply Changes.



11. Before the Parameters of the test can be configured, Super Flows must be created and configured. From the
Managers drop down menu, select Application Manager.

12. When prompted about saving the test, select Yes.



13. Enter a name for the test in the required field and click Save.

14. Select the Super Flows tab.



15. A new Super Flow must be created. Click the Create a new Super Flow (‘+’) button (located under the list of Super
Flows).

16. Enter a name for the Super Flow that will be easy to recall when creating the App Profile. Click OK once completed.



17. Click the Manage Hosts button under Step 1 – Define Hosts.

18. A client and a server host should already be created. No other hosts are required. Click Close once completed.

19. Next, the flows must be defined. In Step 2 – Define Flows, make sure Client is set to Client and Server is set to
Server. Use the Protocol drop down menu to select HTTP and then click Add Flow (‘+’).



20. Next, an action for this flow must be defined. In Step 3 – Define Actions, use the Action drop down menu and select
Client: GET, and then select Server: Response 200 (OK). After selecting each action, make sure to click the Add
Action (‘+’) button. Also, make sure that the Flow is selected from Step 2 or you will not be able to add an action.

21. Next, the Actions must be configured. Select the Client GET action (first one in the list) and select the {…} button.



22. Make sure Transaction Flag is enabled and set to Continue and that Enable persistent HTTP sessions is enabled
and set to off. Everything else should be disabled. Once the configuration is completed click Apply Changes.

23. Select Server Response 200 (OK) in the Action list and click the {…} button.



24. Most of the defaults are already configured correctly. Double check to make sure Transaction Flag is set to Continue,
HTTP Compression is set to none, Keep Alive is off, Generate ‘Content-MD5’ header is off, and Enable chunked
encoding is off. Also, make sure HTTP chunk response size is set to 64. Scroll down so the rest of the list is visible.

25. Set Random response min length to a value of 1024. This will make the server respond with a 1k page. Disable
Random response max length. Click Apply Changes once completed.



26. The configuration for this Super Flow is complete. Click Save Super Flow.

27. Repeat steps 14 to 25 creating 3 new Super Flows and each should have a unique name and be configured with a
Random response min length value of 4k, 8k, or 12k.



28. One last Super Flow needs to be created. This Super Flow will transmit Flash data from the server to the client.
Repeat steps 14 to 22. Once in the Response 200 (OK) editor change Transaction Flag to End. Also, make sure HTTP
Compression is set to none, Keep Alive is set to off, Generate ‘Content-MD5’ header is set to off, and Enable

Scroll down until the rest of the parameters are visible.
chunked encoding is set to off. Next, change Content-Type to video/flv and File Generator to Flash (video/flv).

29. Set Random response min length to a value of 102400 and disable Random response max length. Click Apply
Changes once completed.



30. The configuration of the Flash Super Flow is complete. Click Save Super Flow.

31. Select the App Profiles tab.



32. A new Application Profile must be created. To the Application Profile, we will add all the newly created Super
Flows. This allows the ability to create a more complex test and have different Super Flows that can contain different
protocols. In this test scenario, we are using only HTTP traffic. Select the (‘+’) button to create a new Application
Profile.

33. When prompted enter a name for the Application Profile, something easy to remember as this will be used again
shortly. Click OK once completed.



34. Locate the list of Available Super Flows. The five Super Flows just created should be in the list. Also, the list might
be longer than one page, so make sure to navigate through all the pages if needed. Locate each of the newly created
Super Flows, and then click the down arrow button to add to the Application Profile. Use the Shift button to select
multiple Super Flows.

35. Save the Application Profile by clicking the Save App Profile button.

36. Now that all the Super Flows and the Application Profile have been configured, click the Return to previous screen
button to configure the rest of the test parameters.



37. Select the Parameters tab.

38. In the Data Rate section, change Minimum data rate to 1000. This will change the line speed to Gigabit. Click Apply
Changes once completed.

39. Under the Session Ramp Distribution section, several parameters need to be changed. Using the Ramp Up
Behavior drop-down menu, select Full Open + Data + Close. Next, change Ramp Up Seconds to 1460 (again, this
is a calculated value; see the first test for how to calculate it) and verify Steady-State Behavior is set to Open and
Close Sessions. Finally, scroll down until the final three parameters are visible. Change Steady-State Seconds to 120,
Ramp Down Behavior to Full Close and Ramp Down Seconds to 30.



40. Changes are required in the Ramp Up Profile. Change Ramp Up Profile Type to Stair Step. Set the Minimum
Connection Rate to 500, this will be the initial number of connections attempted. Next, set the Maximum
Connection Rate to 7300. Scroll down to configure the last two parameters. Set the Increment N connections per

attempts every 10 seconds. Click Apply Changes when done.
second to 50. Finally, set Every N seconds to 10. The last two parameters configured will add 50 new connection

41. Under the Session Configuration, set Maximum Simultaneous Sessions to 7500000 and Maximum Sessions Per
Second to 750000. Click Apply Changes once completed.

42. Finally, scroll down to the Application Profile parameter. Using the drop-down menu, select the newly created
Application Profile and click Apply Changes.



43. Verify the Test Status has a green check mark. If it does not, click the Test Status link and make the required changes.

44. Under Test Quick Steps, select the fourth option, Save and Run.

45. When the test starts, the Summary tab displays and provides a nice overview of what is happening within the test.



46. Select the TCP tab and verify that connections are being successfully established.

47. Another nice resource to view is the Application tab. This provides information about each protocol (if multiple
protocols are being run). In this case, as only HTTP is being used it provides the same information as can be seen on
the Summary and TCP tab.



48. Select the TCP tab to view the TCP Connections per second. Although this test does take a while to run, be sure to
monitor the test. At some point during the test, the Attempted and Successful rate should differ. If these states do not
differ, wait until the test has completed, and then redo the parameters and increase the Maximum Connection Rate
and the Ramp Up Seconds accordingly as the test did not reach the limit the Load balancer was able to handle.

49. Let the test finish. You will be notified the test failed; this is okay. Select the Close button.



50. Select the View the report button.

51. Expand the Test Results for HTTP Traffic and then expand the Details folder. Select Superflow Summary in the
navigation panel. This will show the weight of each page as configured (since it was left as default, each should have a
weight of 20%) and the Effective Weight. The Effective Weight is the actual weight that was transmitted to the DUT.

52. Next, select Component Concurrent Flows. This will display a graph and a table of how many TCP Flows were active
at a specific time during the test.



53. Select TCP Connection Rate. Again, a graph and a table will be displayed. This view displays very detailed
information about the client and server TCP establish, close and attempted rate.



54. Select the Frame Data Rate view. This will display a graph and table of the data rate at certain intervals.

Other tests can be performed using:

• Different sizes of HTTP pages.
• More or fewer HTTP pages.
• Different types of HTTP pages.
• Increased numbers of supported back-end servers to 10%, 25%, 50%, 75% and 100%.



HTTPS/SSL
RFC:
• RFC 2818 – HTTP Over TLS

Overview:
Load balancers can use SSL to help relieve some of the processing required of a Web server to handle SSL. The client makes an SSL request
to the load balancer, and the load balancer makes a normal unencrypted HTTP request to the Web server. The BreakingPoint Storm CTM will
be configured with two test components. One will be the SSL Clients, and the other will be a Web server. This test will help determine the
load balancer’s ability to offload SSL from the Web server.

Objective:
Determine the ability of the load balancer to handle SSL connections and the rate of SSL Connections per second it can handle.

Setup:



1. Log into the BreakingPoint Storm CTM.




3. Select Test  New Test.

4. Select Select the DUT/Network from Test Quick Steps.



5. It might be possible to reuse the Network Neighborhood created in the first test. If your configuration allows for this,
you should select the Network Neighborhood created in the previous test. Then, under the Device Under Test(s),
select the BreakingPoint Default option. Click Accept once completed and go to Step 11. If your configuration does not
allow for the reuse of an existing Network Neighborhood, continue to the next step.



6. Click Open network neighborhood screen.

7. Locate the Network Neighborhood created in the first test and then click the Save As link. This will create a duplicate
for easier configuration changes.



8. Enter a name of Load Balancer SSL for easy recognition for later use and click OK.

9. Select the Interface 2 tab. Make changes to the Minimum IP Address and Maximum IP Address as required. Click
Apply Changes and then Save Network (this will be enabled after you have applied the changes).

10. Click the Return to previous screen button.



11. Select BreakingPoint Default for the Device Under Test(s). For the Network Neighborhood(s), select the Network
Neighborhood that was just created. Click Accept once completed.

12. When prompted about the current test setup containing more interfaces than the newly selected one, select Yes.




14. Select Session Sender (L4) for the component type.



15. Enter a name of SSL Client under the Information tab and click Apply Changes.

16. Select the Interfaces tab. Enable the External Server and disable the Interface 2 Server for this test component.
Another test component will be created later that will be used as the Interface 2 Server. Click Apply Changes once
completed.

17. Select the Parameters tab.



18. Under the Data Rate section, change the Minimum data rate to 1000 and click Apply Changes.

19. Under the Destination Port section, change the Port distribution type from Random to Constant. Also, change the
Minimum port number to 443 since this is the standard port for HTTPS. Click Apply Changes once completed.

20. In the Session Ramp Distribution section, change the Ramp Up Behavior to Full Open + Data + Close. Also, change
the Ramp Up Seconds to 600. Since this test involves only the ramp up, no steady-state is required. Change the
Steady-State Seconds to 0. Finally, change the Ramp Down Seconds to 30 and click Apply Changes.



21. Under the Ramp Up Profile section, change the Ramp Up Profile Type to Stair Step. Set the Minimum Connection

stated previously, set Increment N connections per second to 2 and the Every N seconds to 1.
Rate to 2, as the test will step 2 connections every 1 second. Also, set the Maximum Connection Rate to 1200. As

22. Since the Maximum Connection Rate is 1200, you will need to set Maximum Simultaneous Sessions and Maximum

change the Target Minimum Simultaneous Sessions and Target Minimum Sessions Per Second to 0. Click Apply
Sessions per Second to 15000 (this is the maximum for SSL/TLS, but these rates will not be reached in this test). Also,

Changes once complete.



23. Set the SSL/TLS Configuration.Enabled parameter to true and change Minimum Version to TLSv1. Click Apply
Changes.

24. Locate the CA Certificate field and select the Import link.



25. In the page that opens, use the Choose File button to select the CA certificate located on your system. Click the Upload
button once selected. If the page does not open up, check the browser settings and disable popup blocking.

26. Back in the main configuration screen, use the CA Certificate drop-down menu to select the certificate just uploaded
to the system. Click Apply Changes once completed.



27. Next, the HTTP Server needs to be created. Since most of the parameters will be the same, it is easier to clone the test
component you just created. Right-click on SSL Client and select Clone Component.

28. Select the new component and then the Information tab.

29. Enter a name of HTTP Server for this test component and click Apply Changes.



30. Select the Interfaces tab and make sure only Interface 2 Server is enabled. Click Apply Changes once completed.

31. Select the Parameters tab. One modification will be made to the existing parameters.

32. In the Destination Port section, locate the Minimum port number. This value needs to be changed to 443. This is
because Web servers do not handle any of the encryption; the load balancer handles the entire encryption load. Click
Apply Changes.



33. Verify that the Test Status has a green check mark next to it. If it does not, select the Test Status link to view the
configuration.

34. Select Save and Run from Test Quick Steps.

35. Enter a name for the test, such as Load Balancer SSL, and click Save.



36. Select the TCP tab and make sure connections are being successfully established.

37. Next, select the Encryption tab. Verify that SSL handshakes are being successfully completed from the SSL Handshakes
per Second graph.



38. Click the Close button when the test completes.

39. Select the View the report button. The report will open in a Web browser.



40. In the Web browser that appears, expand Test Results for SSL Client, and then expand the Details folder. Notice all
the SSL/TLS results that are collected.



41. The first SSL/TLS result of interest is the SSL/TLS Handshake Rate. This result is the rate at which the load balancer
is able to handle SSL/TLS connections. Select SSL/TLS Handshake Rate to view the results.

42. Notice that a graph and a table of results are loaded. Using just the graph, it is possible to determine that the most
Handshakes Started/s occurred right around 100 seconds before any Handshakes Aborted/s started to occur.



43. Scroll down to the timestamp just noted. Locate the value right before any Handshakes Aborted/s occurs (the last
column). We are looking for this value because if a connection is aborted, then the load balancer is not able to handle
any more SSL connections per second. In the current example, about 196 SSL Handshakes/s are possible for the load
balancer to handle.

44. Next, select the SSL/TLS Handshakes view. A graph and table will load. Again, locate the value right before any

handle before connections are aborted.
Handshakes Aborted happened. This is the maximum number of SSL/TLS connections the load balancer is able to



45. Select SSL/TLS Transactions next. This result view will show a breakdown of SSL transactions started and finished in
a graph and table view.

46. Next, select the SSL/TLS Data Rates view. This will provide a breakdown of the protocol data rate with timestamps.
You can see how added SSL connections will stress the load balancer’s networking capability.

Additional variations of this test can be performed using:

• Different encryption algorithm.
• Different types of Certificates.
• Increased the numbers of supported back-end servers to 10%, 25%, 50%, 75% and 100%



HTTP Caching
RFC:

Overview:
To help relieve some of the stress on Web servers, load balancers are able to cache static items. The test will be configured with two test
components. One will be configured with static data, and the second will be configured with dynamic data. This test will use several images
and several Web pages to help determine a load balancer’s ability to cache the required items.

Objective:
Determine the ability of a load balancer to cache static data and relieve stress from Web servers.

Setup:

This test will require the use of several images. Before starting with the test configuration, either find or create images of
the following sizes:

• 4k
• 8k
• 16k
• 24k
• 188k
• 476k
• 720k



1. Log into the BreakingPoint Storm CTM System.

2. Start a new test by selecting Test  New Test.



3. Select the DUT/Network from Test Quick Steps.

4. Select BreakingPoint Default as the Device Under Test(s). For the Network Neighborhood(s) select the Network
Neighborhood created during the first test. Click Accept once completed.

5. If prompted that the current test setup contains more interfaces than the newly selected one, select Yes.




7. Select Application Simulator (L7) from the Select a component type window.

8. Two test components will be required for this test. Again, select Add a Test Component and select Application

configuration is done, there will be two Application Simulators in the test.
Simulator (L7). One will be used for the imaging caching and the other will be used for dynamic data. When the test



9. Select the first Application Simulator component and change the name to Non Caching Images and click Apply
Changes.

10. Select the second Application Simulator and change the name to Caching Images. Click Apply Changes once
completed.



11. Super Flows will need to be created using several different images of different sizes. For the Non Caching Images
component, we can reuse the one created for the HTTP test. Select Managers  Application Manager.

12. When prompted about saving the test, select Yes.

13. Enter a name of Image Caching when prompted in the Save Test As dialog box. Click Save once finished.



14. Select the Super Flows tab.

15. Locate and select one of the Super Flows created during the first test. Then select the Save As option. This will create
a copy of the selected Super Flow, allowing for quicker configuration.



16. Enter an easy-to-remember name for the Super Flow, such as 4k Image. Click OK once finished.

17. Under Step 3 – Define Actions, select the second item. Select the {…} button to edit the action.



18. Scroll down to the bottom of the new window. Disable Random response min length. Select the Import URI for

Storm CTM.
response data link. This will open a new window that will allow for the images to be uploaded to the BreakingPoint

19. In the newly opened page, click the Choose File button.



20. Browse to the location of the stored images and choose the correct one. Once completed, click the Upload button.

21. Repeat the previous step with the remaining images. This can also be done when creating each Super Flow. When you are
done uploading all the images, close the Web page.

22. Enable the “URI for response data” and using the drop down menu, select the correct image file. Once completed click
“Apply Changes”.



23. Click the “Save Super Flow” button when done.

24. Repeat steps 16 – 18 and 23 – 24 with the remaining image files.

25. Once all the Super Flows have been created, select the App Profile tab.



26. Select the “Create a new Application Profile (‘+’)” button.

27. Enter a name for easy recognition later, such as “Non Image Cache”.



28. Select all the newly created Super Flows and click the down arrow button.

29. Make sure all the Super Flows have been added and then click the “Save App Profile” button.

30. Click the “Return to previous screen” button.



31. The Non Caching Images test component will be configured first. Make sure the first test component is selected and
then select the Interfaces tab. Enable the External Server and then click “Apply Changes”.

32. Next, select the Parameters tab.

33. Under Data Rate, change the “Minimum data rate” to “500” and click “Apply Changes”.



34. Several changes are required under the Session Ramp Distribution section. First, change the “Ramp Up Seconds” to
“5”. Change the “Steady-State Seconds” to “600” and the “Ramp Down Behavior” to “30”. Once completed, click “Apply
Changes”.

35. Several changes are required under the Session Configuration section. First, change the “Maximum Simultaneous
Sessions” to “1500” and “Maximum Sessions Per Second” to “100”. Next, change the “Target Minimum Sessions Per
Second” to “1500”. Click “Apply Changes” when done.

36. For “Application Profile”, select the newly created Application Profile and click “Apply Changes”.



37. Select the Caching Images test component and repeat steps 32 to 36 since the configuration is exactly the same.

38. For “Application Profile”, select the Application Profile created in the first test. Click “Apply Changes” once completed.

39. Verify that the Test Status has a green check mark. If it does not, click the Test Status link and fix the indicated
problems.

40. If desired, enter a Description under Test Information.

41. Finally, click “Save and Run” from Test Quick Steps.



42. Once the test starts, select the TCP tab. Verify that connections are being successfully established.

43. Once the test has completed, close the dialog box.



44. Click the “View the report” button.

45. Each test component will contain its own results section.



46. First, expand Test Results for “Non Caching Images” and then expand the “Detail” folder. Select “TCP Server State
Machine” from the list.



47. The graph shows that Server State “ESTABLISHED” (TCP Sessions) is stable during the running of the test. Also, scroll
down the Server State “ESTABLISHED” (TCP Sessions) column to verify the requests were made to the server for the
pages.



48. Next, expand Test Results for “Caching Images” and then expand the “Detail” folder. Select “TCP Server State Machine”
from the list.



49. The graph shows the initial ‘Server State “ESTABLISHED” (TCP Sessions)’ connections, and once the load balancer starts
to cache the pages, the connections stop. Scroll down the ‘Server State “ESTABLISHED” (TCP Sessions)’ column to verify
that large amounts of requests were not made to the server for the pages.

Variations of this test can be performed as follows:

• Larger number of images
• Larger number of static pages
• Longer test duration
• Increase the number of supported backend servers to 10%, 25%, 50%, 75% and 100%



Dual Traffic HTTP and IMAP
RFC:
• RFC 3501 – Internet Massage Access Protocol – Version 4rev1

Overview:
The load balancer should be configured with both port 80 (default HTTP) and 143 (default IMAP) open. The BreakingPoint Storm CTM
will be configured with two test components. The first test component will use the HTTP protocol and the second one will use IMAP. The
BreakingPoint Storm CTM will act as both the client and server for each protocol. Each test component will be configured to step the
connection rate at a different interval. The results will be viewed to determine how the load balancer is able to handle multiple traffic streams
from multiple protocols.

Objective:
Determine the load balancer’s ability to handle multiple protocols and process the incoming data at a reasonable rate.

Setup:

1. Log into the BreakingPoint Storm CTM.



3. Select Test  New Test.


4. “Select the DUT/Network” from Test Quick Steps.

5. This test will require both HTTP and IMAP servers, so a new Network Neighborhood will be created. Click the “Open
network neighborhood screen” link.

6. Select the Network Neighborhood created in the first test and select “Save As”.



7. When prompted for a new name for the Network Neighborhood, enter in “IMAP/HTTP” for easy recognition later.

8. Interface 1 is already configured correctly. Select the Interface 2 tab and click the “Create a new domain (‘+’)” button.



9. When prompted for a name, enter “IMAP” and click “OK”.

10. Most of the configuration is correct. Update the “Minimum IP Address” and the “Maximum IP Address” as required.



Click “Apply Changes” once completed.

11. Select the External tab and click the “Create a new domain (‘+’)” button.

12. When prompted for a name, enter “IMAP” and click “OK”.

13. Select IMAP from the Domains list and select the entry in the Subnet section. Click the “Delete” button to delete the


entry.

14. For the new subnet, disable the “Use Address Range” option. Enter in the configured IP Address of the external
interface to use. Click “Add Range” once completed.

15. Verify that the IP has been added to the Subnet field, and then select the “Test Paths” button.



16. Select “Specifically defined test paths”. Then, using the drop down menus, make sure the first one is set to “Interface1:
default” and the second one is set to “External: IMAP”. Click “Add” to add the test path. Click “Close” once completed.

17. Finally, click the “Save Network” button.



18. Click the “Return to previous screen” button.


Server Load Balancer Test Methodology

Server Load Balancer Test Methodology

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Server Load Balancer Test Methodology

Similaire à Server Load Balancer Test Methodology (20)

Plus de Ixia

Plus de Ixia (19)

Dernier

Dernier (20)

Server Load Balancer Test Methodology