Jenkins Installation for Windows

Visit Jenkins site and download it for Windows. It will be .msi file.

Then, extract the file and it will save itself in Program Filex(x86) under Jenkins folder.

Now open command promt and go to directory where Jenkin folder is present and run below command

D:\>Java –jar Jenkins.war

It should end successfully. However in case you get failure, there can be two main reasons.

a. Incorrect Java version or Java path:

Jenkins requires latest version of Java and you will need to download if from net. Then set the java path as below:

set JAVA_HOME=C:\Program Files\Java\jdk1.8.0_161
set PATH=%JAVA_HOME%\bin;%PATH%;

b. Port 8080 is already in use

Most of the application uses port 8080 as it is a default port. In case you too see similar issue, you can change the port from 8080 to something say 8081.

Below are steps:
If you run Jenkins using the command line, then you can execute a command such as java -jar -httpPort=8081 jenkins.war to change the existing port from 8080 to 8081.

Another way to change the port while Jenkins is installed using the Windows package is as follows:

Go to the Program Files/Jenkins directory where you installed Jenkins
Open the Jenkins.xml in the editor
Find "--httpPort=8080" and replace the port 8080 with the new port number

After you have made any changes, it is better to restart Jenkins. To restart

Press Win + R.

Type "services.msc"
Right click on the "Jenkins" line > Restart.

Then go to URL: http://localhost:8082/

It was ask you to provide passward. Don't worry, it will also show you how to get password.

To create additional user, login with admin account and follow below step:
Manage jenkins → Manage User → Create User.

Hope you enjoy learning Jenkins.

Load Runner Analysis and types of graphs

First let's see what is Loadrunner Analysis and then see some important loadrunner graphs.

Analysis:

• Analysis is the utility or program to analyses the LoadRunner results in a very detailed manner.
• LoadRunner results are saved in .lrr file(lrr stands for Loadrunner Result) and can be viewed using Analysis.
• Analysis gathers the result information from scenario results (lrr file) and stores the information in form of .lra file.
• LoadRunner result has “Log” folder which contains Vuser logs and saves snapshots on error.
• Analysis generates Analysis Summary for the test which gives good idea about the test.
• Analysis generates graphs from the data collected during the test execution.
• Few of the graphs which are important for analysis of the results are Running Vusers, Hit per second, Throughput, Transaction Summary, Average Transaction Response Time, Error per second, etc.
• Analysis provides the raw data from which graphs are created.
• The granularity of graph should be such that it has maximized readability along with accurately represent important events.
• Analysis also provides facility to compare the results for the test.
• Analysis has good reporting mechanism which is helpful in sharing the test results.
• In Analysis, customized templates can be created to generate the same report for other test results.
• Loadrunner provides many formats to save the report. You can save you result in HTML format and share with the clients.

Graphs:

There are many types of graphs in Loadrunner results but you see only the default one when you load the results. Also, not all of them are important and and of course Average Transaction Response time is usually the graph your client always want to see.

Below are few types of graphs that you should know that exists in Loadrunner. I have explained which are important.

Running Vusers Graph
This graph would give the number of Virtual users that were incremented during the course of the load test.

Vuser Summary Graph
Lets you view the number of Vusers that successfully completed the load test scenario run relative to those that did not. Lets you view the number of Vusers that successfully completed the load test scenario run relative to those that did not

Rendezvous Graph
It indicate when vuser were released from rendezvous point and how many vuser are released from each point.it help the transaction performance time

Error Statistics Graph
This graph displays the number of errors that occurred during load test scenario execution, grouped by error code.

Error Statistics (by Description) Graph
This graph displays the number of errors that occurred during load test scenario execution, grouped by error description. The error description is displayed in the legend.This graph can only be viewed as a pie.

Total Errors per Second Graph
This graph displays the average number of errors that occurred during each second of the load test scenario run.

Errors per Second Graph
This graph displays the average number of errors that occurred during each second of the load test scenario run, grouped by error code.

Errors per Second (by Description) Graph 

This graph displays the average number of errors that occurred during each second of the load test scenario run, grouped by error description. The error description is displayed in the legend.

Average Transaction Response Time Graph

This graph gives the average transaction response time for all transactions executed by all users. This is a good graph to get an indication of how the application is performing. There can be a spike during the beginning of the load test in terms of response time, because initially the application needs time to scale its resources as per the load. But you should then start to see a gradual decrease and stabilization of the transaction response time. If you don’t then this can be an indication that there is an issue with the application.

Transactions per Second Graph

This graph displays, for each transaction, the number of times it passed, failed, and stopped during each second of a load test scenario run.

Transaction Summary Graph

This chart is good in understanding the ratio of passed to failed transactions. The green bar represents the number of passed transactions and the orange one the number of failed transactions. So if you see a larger number of failed transactions, this would give an indication. You can further Drilled Down Transaction Summary by doing right click and choosing Drill option.

Transaction Performance Summary Graph

This gives a summary of the minimum, average and maximum time of transactions in the load test.

The graph will then be displayed as shown below when you add this to the Analysis session.

Transaction Response Time (Under Load) Graph

This graph is a combination of the Running Vusers and Average Transaction Response Time graphs and indicates transaction times relative to the number of Vusers running at any given point during the load test scenario.

Transaction Response Time (Percentile) Graph

This graph helps you understand whether your response time meet the accepted criteria.

The graph will then be displayed as shown below when you add this to the Analysis session.

Transaction Response Time (Distribution) Graph
This graph displays the distribution of the time taken to perform transactions in a load test scenario

Hits per Second Graph

This graph would provide the number of hits by the load test against the application. This graph is good to see if the load test was consistent in hitting the application with requests at the right intervals.

Throughput Graph

This graph would provide the number of bytes that was received by the Web server. This graph gives a good indication of the throughput of the application. If the throughput decreases as the user load increases then that can signal an issue in the application.

HTTP Status Code Summary Graph

This graph shows the number of HTTP status codes returned from the Web server during the load test scenario run, grouped by status code. HTTP status codes indicate the status of HTTP requests, for example, "the request was successful","the page was not found".This graph can only be viewed as a pie.

HTTP Responses per Second Graph

If you want to see the HTTP Responses per second, you need to go to the Summary Screen and click the ‘HTTP 200’ link in the HTTP Response Summary section. The HTTP Responses should be consistent throughout the load test. If the responses starts to decrease even though the number of users is high, that would indicate that there is an issue with the application.

Pages Downloaded per Second Graph

This graph shows the number of Web pages downloaded from the server during each second of the load test scenario run.

Retries per Second Graph

This graph displays the number of attempted server connections during each second of the load test scenario run.

Retries Summary Graph

This graph shows the number of attempted server connections during the load test scenario run, grouped by the cause of the retry.

Connections Graph

This graph gives the number of connections during the elapsed time of the load test. Obviously during the beginning of the load test, it should increase and decrease towards the end of the load test.

The graph will then be displayed as shown below when you add this to the Analysis session.

Connections per Second Graph

This graph gives the number of new connections and the number of connections which were shut down during the course of the load test.

The graph will then be displayed as shown below when you add this to the Analysis session.

Page Component Breakdown Graph

This is a useful graph for finding any response time issues per page. In this the response time for each page over the duration of the load test is provided.

The graph will then be displayed as shown below when you add this to the Analysis session.

Page Component Breakdown (Over Time) Graph

This graph displays the average response time (in seconds) for each Web page and its components during each second of the load test scenario run.

Page Download Time Breakdown (Over Time) Graph

This graph gives the time each page took to download from the server. If the time is high, then this is a cause of concern for the application.

Time to First Buffer Breakdown (Over Time) Graph

This graph displays each Web page component's relative server/network time (in seconds) for the period of time until the first buffer is successfully received back from the Web server.

Downloaded Component Size Graph
This graph displays the size of each Web page component.

Windows Resources Graph

This graph shows the Windows resources measured during the load test scenario. The Windows measurements correspond to the built-in counters available from the Windows Performance Monitor.

UNIX Resources Graph

The UNIX Resources monitor shows the UNIX resources measured during the test run. This graph helps you determine the impact of Vuser load on the various system resources.

SiteScope Graph

The SiteScope Resources monitor graph shows the SiteScope resources measured during the test run. The SiteScope monitor can measure server, network, and processor performance counters.

Merging graphs

Merging graphs can be useful when you want to view the information in 2 graphs at the same time. This can be useful for comparing results. Ensure that when you are merging graphs that at least one graph is open.

Let’s choose the Hits per second graph and then choose the Merge Graphs option from the Context menu.Then choose the option to merge the graph with the Running VUsers and then click the OK button.You will then get the complete picture of the number of hits per second as per the virtual users. The sample result is shown below.

Merging Types Overview
Overlay:
Superimpose the contents of two graphs that share a common x- axis. The left y-axis on the merged graph shows the current graph's values. The right y-axis shows the values of the graph that was merged. There is no limit to the number of graphs that you can overlay. When you overlay two graphs, the y-axis for each graph is displayed separately to the right and left of the graph. When you overlay more than two graphs, Analysis displays a single y-axis, scaling the different measurements accordingly.

Tile:
View contents of two graphs that share a common x-axis in a tiled layout, one above the other

Correlate:
Plot the y-axis of two graphs against each other. The active graph's y-axis becomes the x-axis of the merged graph. The y-axis of the graph that was merged, becomes the merged graph's y-axis.

Loadrunner Details - Recording options, scenario and Parameter

In this Blog, i am trying to clear some basic queries and as well helping to provide some basic information. This may help you in when you are just starting to learn this tool or while preparing yourself for some exams.

Recording Option - HTML based or URL based

HTML based scripting:

It records script from every user action that is performed during recording.

It does recording as you perform clicks and doesn't give you inside information like what is happening behind the recording.

It is smaller and is more intuitive to read as the statements are inside the functions corresponding to the user action performed.

It is recommended for browser application.

The advantages of using the HTML recording mode is that the size is very compact and the customization efforts reduced.

However, with UI changes to the web applications the scripts would require much higher maintenance costs.

URL based scripting:

It records each and every browser requests to the server and resources received  from the server.

It records each and every step and emulate Javascript code.

In this mode all the statements gets recorded into the web_url().

It is recommended for thick client application.

LoadRunner does server side testing.

Transaction Percentile in Loadrunner result

In summary report of Loadrunner result, you might have seen 90 percentile column.

This is usually to check if we have met SLA. We can similarly have other percentile value as well. By default, LoadRunner provides 90 percentile result.

We can change the percentile result as per our need. Click on 'View' in Menu bar. Then Click on summary Filter. A dialog box will open and you will Additional Setting. There you can change the Transaction Percentile value from 90 to whatever you need. Usually, the client requirement is to check 90,95,98 or 99 percentile.

The question is what is this percentile and how do we calculate them manually. In order to calculate the 90 percentile response time for a transaction, sort all the response time values for that transaction in ascending order. Take the first 90 % transactions out of this set. The response time that has the maximum value in this set is the 90 percentile value of the studied transaction. In other words maximum response time for best 90 percentage of the transactions.

Types of Scenario

When we launch controller, we are asked to select the type of scenario that we want during our load test. We have two options for it - Manual or Goal Oriented. Let see them brief...

Manual scenario:

When you choose manual scenario you create it by selecting scripts to run, providing load generators on which we need to run the scripts, and distributing Vusers to run among the scripts. We provide all these details manually and hence the name.

We also have to provide details for Vuser that how we want to distribute them. We have two mode again - Quantity wise or percentage.

Vuser group mode - In this, for each script you assign a number of Vusers. You can instruct all Vusers in a group to run the same script on the same load generator, or you can assign different scripts and load generators to the various Vusers in a group.

Percentage mode - In this, you define a total number of Vusers to be used in the scenario, and assign load generators and a percentage of the total number of Vusers to each script.

Goal-Oriented Scenarios:

In this scenario, you define the goals you want to achieve and LoadRunner automatically creates a scenario for us based on these goals. We usually define our goal based on below types of goals.

Types of Goals:

Virtual Users - This goal tests if your application can run a specified number of Vusers simultaneously. Running this type of goal-oriented scenario is similar to running a manual scenario.

Pages per Minute/Hits per Second/Transactions per Second - These goals test the strength of your server. For each of these goal types, you specify a minimum-maximum range of Vusers for the scenario to run, and in the case of the Transactions per Second goal type, you also specify a transaction name.

Transaction Response Time - This goal tests how many Vusers can be run simultaneously without exceeding a desired transaction response time.

Run as thread or Process

Loadrunner provides as option of Multi-threading. We have two ways to run it - Run Vuser as a thread or Run Vuser as a Process.

When we run Vuser as a process, LoadRunner creates one process called mmdrv.exe per Vuser. So if we have 10 Vusers running, we will have 10 mmdrv.exe processes on our machines.

While when we run Vuser as a thread, LoadRunner creates 1 thread per Vuser. So if we have 10 Vusers, then we will have 1 process with 10 threads running inside it if the limit is 10 threads per process.

Thus from the memory point of view while running a load test, running Vuser as a thread is more memory efficient that running Vuser as a process for obvious reasons that less memory resources are utilized when we run them as thread.

Types of Parameter

We have below list of parameter types when we do parameterization while enhancing our recorded scripts.

Custom

Date/Time

File

Group Name

Iteration Number

Load Generator Name

Random Number

Unique Number

User defined functions

XML

Vuser ID