1.

Performance Basics
- Performance testing can only be done when all major critical defects have been fixed.
- For High transactional applications, performance testing is done at ever functional level (At every
thread level). Basically, it is done to check how many levels of threads the application can take.

- Performance testing cannot be done manually. Because:

1. In manual testing we write scenarios and match the results with my expected result. So, in this case,
our actual result won’t be accurate. In other words, the results cannot be quantified. Hence, it is not
advisable to do performance tests manually.
2. Performance testing requires a lot of users. So, the question is always about how many users the page
will accept. Obviously, we cannot have many users come in at the same time. It would cost a lot of
money, time, effort.
- The tool takes care of accuracy, load and synchronization.
- Performance testing can only be done on end-to-end scenarios. It is done on processes that are
complete. Transaction has to be complete. Transaction represents end-user business processes that you
are interested in measuring

Queries that make requests to the server is end-to-end. E.g. ‘Submitting’ a query can be an end
scenario.

- Performance Types
> Load
> Performance Testing (Load and performance go hand-in-hand.)
> Stress/Endurance Testing
> Soak testing
> Spike Testing
> Disaster recovery testing

- Load
- Traffic that is pushed onto a server is called a load. Performance testing is done by creating Virtual
Users (VUsers). To amount of load is checked by using probes.
- Against the load, we can check how the performance of my server is.
- There are many tools that can do network monitoring.

- Stress Testing
- Testing to a point at which the application will break. It involves pushing the application capacity till it
cannot take it anymore.
- Used to test scalability

- Disaster Recovery Testing/Failover Testing

- Generally done in test exchanges.
- It involves switching off primary servers to check if the traffic gets transferred to the backup server
(Slave servers).
- These slave servers are synchronized with the primary servers
- Soak Testing
- Involves pushing the load to the server for a long duration of time.
- This helps to identify memory leaks.
- Memory leaks are objects whose references are not present but, which are still residing in the
memory. They don’t have any purpose. These objects take unnecessary CPU load.
- In Soak testing, we keep the load for a long duration and then check/analyse load. Check RAM if it is
eating the memory.

- Spike Testing
- Includes drastically increasing the traffic on the server to check how it handles the sudden surge.
- Application might not be able to comprehend the sudden increase of traffic.

- What do we measure?

- CPU usage
- Memory usage
- Hits/second – Any request from a server is a hit.
- Throughput - Throughput is measured by the number of hits. It is always measured in bytes/sec and
checks how much data has the server transferred.
When the server is hit, more data is hit. Hence, the throughput should go up when the hits go up.

- Hits/sec become flat as the number of VUsers increase. This is caused due to problem with the
Database Server. There may be caused due to deadlock.

- Difference between WebServer and AppServer.

Webserver redirects traffic. Page not found error occurs because web server does not get where is it has
to get the data from. Application servers are used to serve pages for viewing data in a Web Server. App
Server is where the business logic comes in. App Server only runs the logic.
- Performance testing is always done in isolated environments.

- How does LoadRunner work?

- First the tool records the test.
- When the test is opened, LoadRunner acts as a proxy and sniffs traffic. Proxy does filtering.
- LoadRunner sniffs based on a protocol (http). It understands the language between the client and the
server.
- LoadRunner understands various types of protocols. Namely, Socket level, http, java, sap, media. That
is why it is highly famous.
- It also generates script.
- When the test is run, the tool directly fires the traffic onto the application. No Web servers are used.
When application responds, it gives an accurate time instead of including the browser response time.
The extra response time of the browser is called GUI rendering time.

- Load Generators
- Load Generator creates the load by running virtual users.
- How to control multiple users.
- Load Generator specifies the number of users and the control machines.

Features of LoadRunner
- VUGen – VUgen is used for record and playback.
- Controller – Decides the strategy to fire traffic. Strategies include Ramping up traffic (i.e. Shooting at
intervals) or Linear (generate traffic at every point).
- Analysis- Collates the data which it gets from the user.
- ThinkTime – While recording, the time difference between performing functions is seen as a ThinkTime
by LoadRunner.

- Two ways to generate script?

1. Parametrization
2. Correlations

Correlation
- Get value for the object and pass it for sending requests.
- LoadRunner gives a message if correlation is not possible.

Parametrization
- Takes data from an external source.

File Extensions:
.lrr – Load Runner Result
.lrs - Load Runner Scenario

Note:
Performance testing cannot be done for standalone applications.