VUGen replay errors for HTTPS sites

Problem Statement: Now as most of the sites are migrating to HTTPS; during replay of these application(s) / sites you might see some errors as mentioned below; you can follow the solutions given to resolve the same.

Solution:

Below are a list of Errors encountered and their resolutions for the same:

Error: "--27776: Server "[server_name]" shut connection during attempt to negotiate SSL session"

To resolve this issue, you can reduce the amount of connections simultaneously opened to a Web server by using the following statement in the script:

web_set_sockets_option("MAX_CONNECTIONS_PER_HOST","1");

Also, make sure that Keep-Alive is set to "No." This setting can be found via Run-Time Settings -> Preferences -> Options -> Keep-Alive HTTP Connections.

Error: "Error -27781 Timeout in state STATE_SSL_CONNECT "

Error: -27778 : SSL protocol error when attempting to read with host

There are some possible work-around for the above 2 errors, you need to check which one (or combination) works for you:

1. Add the following statement to the beginning of the script:

        web_set_sockets_option("SSL_VERSION", "3");

You can check the SSL Version in your recording log of the script, it can be TLSv1.1 / 1.2 or SSL3; accordingly you can change the command mentioned above.

2. Add web_set_sockets_option("MAX_CONNECTIONS_PER_HOST","1"); at the very beginning of the script.

This forces a single connection to the server thus eliminating the possibility of the server prematurely shutting down an existing connection and causing errors when LoadRunner sends data using that connection.

3. Disable webpage breakdown if HTTPS protocol (SSL) is being used and there is a proxy server in-between the client (LoadRunner) and the server under test. To disable webpage breakdown from the Controller:

   a. Go to Diagnostics->Configuration.

   b. Select "Disable" tab for "Web Page Diagnostics"

   c. Click "OK" to close the diaglogue to complete the setup

4. If you have generated your script using WinInet options then use the WinInet Replay engine. To do so, go to Run-Time Settings -> Preferences -> Select "WinInet Replay Engine instead of Sockets (Windows Only)."

Error: "SSL State: error in SSLv3 write client certificate B..." while replaying in Socket mode

Error: "SSL protocol error when attempting to connect with host" while replaying a Web protocol script

Add all of the certificates in the certificate hierarchy for the SSL certificate to a .pem file (e.g. certFile.pem) and include this .pem file by adding the following line at the beginning of the script:

web_set_certificate_ex( "CertFilePath=certFile.pem", "CertFormat=PEM", ...LAST);

web_set_sockets_option("LOAD_VERIFY_FILE", "certFile.pem");

Error -27791 : "server name" has shut down the connection prematurely

To Resolve this, you can try adding the below command:

web_set_sockets_option("MAX_CONNECTIONS_PER_HOST","1"); at the very beginning of the script.

If you still get the same error then you can try the below command (add it after the previous one):

web_set_sockets_option("IGNORE_PREMATURE_SHUTDOWN", "1")

Error: SSL protocol error when attempting to connect with host "xxx"

Try to check the certificate and connection using openssl with this sentence from CMD:

                       openssl s_client -connect :2443

               or

                       openssl s_client -connect :443

This will show the certificate information. If not, application has a certificate problem and need to check with application owners / server admins.

Performance environment scaling and results extrapolation

In this article we shall discuss about the points we have to consider when we get a new environment or existing environment for performance testing.
Rule 1 - The configurations of Production and test env should match
eg - if they have 4 web, 2 app and 2 Db servers
test env might be 2 web, 1 app and 1 DB but not 1 web, 2 app, 1 Db etc....

Rule 2 - JVM heap memory should match
Prod 2 JVM with 4GB heap each
test has 1 JVM with 4 GB heap but not 1 JVM with 3GB
Rule 3 - The log settings of test and prod should match
Rule 4 - Check for the connection limits of all servers (limit should be w.r.to the performance tests we perform on that env)
Depending on the above responses and some more info specific to that env, we do the scaling.
Results extrapolation:-
Rule 2 is most important while doing extrapolation, as the available memory on that server is not important but the heap memory allocated is important and that is what we compare with production - not the total memory of server.

If you just have 1 JVM and have to extrapolate to prod with 4JVM's is not practical and results might not be accurate.

For accuracy we might need more than 1 JVM so that we can test with 1 JVM and then with 2 JVM's and then map the results to see the pattern and through curve fitting we can get a formula that can be used to extrapolate.

Note:- if you need more accuracy, you also need more samples
Apart from Rule 2, we also consider all the rules mentioned above to extrapolate the results.

Using string manipulation functions in VuGen/LoadRunner

String Manipulation Functions

String Manipulation functions allow you to manipulate or compare strings. These functions begin with the str prefix. Expand the category to view a list of the available functions.
Click one of the following functions for more information:

Function Name	Description
strcat	Concatenates two strings.
strchr	Returns the pointer to the first occurrence of a character in a string.
strcmp	Compares two strings to determine the alphabetic order.
strcpy	Copies one string to another.
strdup	Duplicates a string.
stricmp	Performs a case-insensitive comparison of two strings.
strlen	Returns the length of a string.
strlwr	Converts a string to lower case.
strncat	Concatenates n characters from one string to another.
strncmp	Compares the first n characters of two strings.
strncpy	Copies the first n characters of one string to another.
strnicmp	Performs a case-insensitive comparison of n strings.
strrchr	Finds the last occurrence of a character in a string.
strset	Fills a string with a specific character.
strspn	Returns the length of the leading characters in a string that are contained in a specified string.
strstr	Returns the first occurrence of one string in another.
strtok	Returns a token from a string delimited by specified characters.
strupr	Converts a string to upper case.

For instance we consider the function STRSTR and see how we use it.....

sample text :- 6172171084 (Service - RPC) Status: Success, Effective Immediately

If you want to capture the above text and try to see if any telephone number & success word is appearing in that phrase, then we use STRSTR function.

Using web_reg_save_param("Confirmation") - Pull that phrase into parameter called confirmation and then use that to validate if mobile number and success message are coming in the server response.

strstr

char *strstr( const char *string1, const char *string2);Returns the first occurrence of one string in another.

string1	The string that is searched.
string2	The string that is searched for in the first string.

strstr returns the first occurrence of one string in another

This is how we do it..........

// If the success message is not displayed, fail the transaction and exit iteration
        if (strstr(lr_eval_string("{Confirmation}"),"Success") < 1)
        {
            lr_error_message("***** Success Message not displayed ******");
            lr_end_transaction("X_RPC_14_SubmitOrder", LR_FAIL);
            lr_exit(LR_EXIT_ITERATION_AND_CONTINUE, LR_FAIL);
        }

        // Dynamic Validation for mobile number
        if (strstr(lr_eval_string("{Confirmation}"), lr_eval_string("{mobile}")) == 0)
        {
            lr_error_message("***** Dynamic Validation Failed for mobile number*****");
            lr_end_transaction("X_RPC_14_SubmitOrder", LR_FAIL);
            lr_exit(LR_EXIT_ITERATION_AND_CONTINUE, LR_FAIL);
        }

Example 1

This example uses strstr to search for the word "dog" in the string, str.
After strstr returns the address, position, the code then calculates the word's place in str by subtracting the address of the start of the string from position. This is the offset of the word "dog", in bytes.

    int offset;

    char * position;

    char * str = "The quick brown dog jumps over the lazy fox";

    char * search_str = "dog";

    position = (char *)strstr(str, search_str);

    // strstr has returned the address. Now calculate * the offset from the beginning of str

    offset = (int)(position - str + 1);

    lr_output_message ("The string \"%s\" was found at position %d", search_str, offset);

Output:
Action.c(14): The string "dog" was found at position 17

Example 2

The next example shows how strstr can be used to parse file name suffixes. The code checks the equality of the following two pointers:

• The pointer returned by strstr after searching for the substring is either null on failure, or the address of the first character of the file suffix on success. Adding 4 moves the pointer to the end of the string.

• The start of the string (path) plus its length, len. This is also the end of the string.

If these 2 pointers are equal than strstr has found the file suffix. If not, strstr has returned null.

    char * path = "c:\\tmp\\xxx\\foo.ocx";

    int len = strlen(path), filetype;

    // Check the suffix of the file name to determine its type

    if ((char *)(strstr(path, ".dll") + 4) == (path + len))

        filetype = 1;

    else if ((char *)(strstr(path, ".exe") + 4) == (path + len))

        filetype = 2;

    else if ((char *)(strstr(path, ".tlb") + 4) == (path + len))

        filetype = 3;

    else if ((char *)(strstr(path, ".ocx") + 4) == (path + len))

        filetype = 4;

    else

        filetype = 5;

    lr_output_message ("type = %d", filetype);

Output:
Action.c(18): type = 4

List of 20 Common Bottlenecks

• Database:
• Working size exceeds available RAM
• Long & short running queries
• Write-write conflicts
• Large joins taking up memory
• Virtualization:
• Sharing a HDD, disk seek death
• Network I/O fluctuations in the cloud
• Programming:
• Threads: deadlocks, heavyweight as compared to events, debugging, non-linear scalability, etc...
• Event driven programming: callback complexity, how-to-store-state-in-function-calls, etc...
• Lack of profiling, lack of tracing, lack of logging
• One piece can't scale, SPOF, non-horizontally scalable, etc...
• Stateful apps
• Bad design: The developers create an app which runs fine on their computer. The app goes into production, and runs fine, with a couple of users. Months/Years later, the application can't run with thousands of users and needs to be totally re-architecture and rewritten.
• Algorithm complexity
• Dependent services like DNS lookups and whatever else you may block on.
• Stack space
• Disk:
• Local disk access
• Random disk I/O -> disk seeks
• Disk fragmentation
• SSDs performance drop once  data written is greater than SSD size
• OS:
• Fsync flushing, Linux buffer cache filling up
• TCP buffers too small
• File descriptor limits
• Power budget
• Caching:
• Not using memcached (database pummeling)
• In HTTP: headers, etags, not gzipping, etc..
• Not utilizing the browser's cache enough
• Byte code caches (e.g. PHP)
• L1/L2 caches. This is a huge bottleneck. Keep important hot/data in L1/L2. This spans so much: snappy for network I/O, column DBs run algorithms directly on compressed data, etc. Then there are techniques to not destroy your TLB. The most important idea is to have a firm grasp on computer architecture in terms of CPUs multi-core, L1/L2, shared L3, NUMA RAM, data transfer bandwidth/latency from DRAM to chip, DRAM caches Disk Pages, Dirty Pages, TCP packets travel thru CPU<->DRAM<->NIC.
• CPU:
• CPU overload
• Context switches -> too many threads on a core, bad luck w/ the Linux scheduler, too many system calls, etc...
• IO waits -> all CPUs wait at the same speed
• CPU Caches: Caching data is a fine grained process (In Java think volatile for instance), in order to find the right balance between having multiple instances with different values for data and heavy synchronization to keep the cached data consistent.
• Backplane throughput
• Network:
• NIC maxed out, IRQ saturation, soft interrupts taking up 100% CPU
• DNS lookups
• Dropped packets
• Unexpected routes with in the network
• Network disk access
• Shared SANs
• Server failure -> no answer anymore from the server
• Process:
• Testing time
• Development time
• Team size
• Budget
• Code debt
• Memory:
• Out of memory -> kills process, go into swap & grind to a halt
• Out of memory causing Disk Thrashing (related to swap)
• Memory library overhead
• Memory fragmentation
• In Java requires GC pauses
• In C, malloc's start taking forever