Home     RSSRSS

Posts Tagged ‘Response’

Transaction Response time–First Indicator of Application Performance

February 14, 2014 by kiranbadi1991 | Comments Off on Transaction Response time–First Indicator of Application Performance | Filed in Performance Center, Performance Engineering, Performance Test Tools, Quality, SilkPerformer, Small Businesses, Web Server

What do you mean by Transaction ?

What do you mean by Transaction Response time ?

Why is the Transaction Response time a key Performance Indicator for the application or system ?

Lot of young people who wants to become Performance Engineer asks me about these types of questions. Seriously I believe Transaction is often associated with the context.For Database DBA it could be something like commit the output of the SQL statement to the DB or rollback the entire output of the SQL Statement and bringing the DBA to its initial state due to some failures.For Developer, it could be related to 1 business requirement equal to 1 transaction and to the banker or domain specialist, it could be one entry in the ledger log.For the prospective of Performance Engineer, it could means any of the 3. It just depends on what is your objective of your tests or what are we looking for measure in the system or application.

The way Performance Engineer sees the transaction is bit different than the way Developer sees them.Some of the examples of the Transaction as seen by Performance Engineer are,

  • Time taken to do the login of the application
  • Time taken to generate and publish the report to the users.
  • Time taken to load the data to the database or Time taken to process xx amount of data and load it into the database(Batch Jobs).

If you look closely at above example, you can see that transaction is always associated with Time. Time taken to do X activity is prime focus of the Performance Engineer.The same might not be true for other folks like DBA,Domain experts or Developers.

One of the reasons as why Performance Engineer always associates time to transaction is because most performance tools have taught us to see transaction this way.Wrap the activity/event/Business functionality between start and end transaction markers and calculate the difference between these start and end time and say that these are our transaction response time for that activity.Most Load testing tools works this way and this logic works for almost 99.9999% of the application.However this kind of logic does not gel well with few of the technologies where non blocking of UI is more preferable than blocking of the UI. Comet/Push are some of the technologies where Marker based transactions do not work favorably unless you do some kind of the hacking.So I believe that Transaction marker based solutions work only for technologies where users waits for the response to come back.

Transaction Response time is most important characteristic of the System Performance from the Users point of view.If they are satisfied with the speed of the system to do more work in short time, then probably no effort is required to speed up the system, else lot of effort is required to increase the speed. Sometimes users are also satisfied with bit of high response time because they know the there is lot analytical calculation program/application has to do to bring data back to them.However when as more and more users starts getting into the system , they start experiencing slowness of the application.Application starts to more time to respond to the users request and the functionality which was taking 3 to 5 sec now starts to give response in 5 to 8 sec.As the user load increases, response time also starts to increase and after a certain point, it fails to respond to the users request.Performance Engineers calls this behavior a breaking point of the application.The reason for the application to stop responding could be many reasons ,however from the performance engineering’s prospective,its suggested that we do bit of analysis based on queuing theory.Rate at which application is receiving requests is more than the rate at which it can serve the requests keeping in mind the environmental constraints.Response time degradation can  happen not only when the number of users or volume of data exceeds some thresholds, but also after the application is up and running for a particular period. A period can be as short as hours or as long as days or weeks. That is often an indication that
some system resources are not released after transactions are completed
and there is a scarcity of remaining resources to allocate to new transactions.
This is called  resource leak  and is  usually due to programming/coding defects.

We say application is having performance issues after analyzing the trend of transaction and can conclude the below points based on data we have collected

    • Transaction response time is getting longer as more users are actively
      working with the system
    • Transaction response time is getting longer as more data are loaded
      into application databases.
    • Transaction response time is getting longer over time even for the same
      number of users or data volume primarily due to leaking of resources like memory,connections etc..

Transaction response time matters a lot when your application is web based application and its public facing site. The revenue of the company depends on how fast the application responds to the user’s request. If your application is internal , then it increases the productivity of the team and company over all.

Tags: , ,

Web Farms: Quick tip to find out which server in the farm is serving the request

June 10, 2011 by kiranbadi1991 | 5 Comments | Filed in Browser, Environment, LoadRunner


Let assume that we have our performance testing environment and in that we have a web farm with 40 servers and portfolio of application hosted on those servers.20 of them are the web servers and rest are web services servers. We also have front end load balancers which balances the load based on least connection algorithm.Then we also have the SSO which is being implemented by Site minder and this site minder protects all the application hosted on this performance environment.

Now lets assume that for some reasons one of the our application is having some issues with load balancer or lets say that with Site minder servers. For some reasons requests are either not getting spread across all the servers or for some reasons cookies is either getting lost in some of the web servers in the server farm. So as the performance engineer, how would you determine which server in the farm is giving an issue or how would you determine on which web server your request is going ?.  I believe the first thing people do, is look at the application logs or web servers logs one by one and see which server the request is being processed.Yes this is an correct solution ,however this consumes lot of time and effort to go through each servers and check individually.Sometimes it so happens that your logs files are in several MB and you can understand the pain it takes to open hundred MB log files.Some times it happens that request is served by only one web server and we check all the servers logs only to find out that later that those servers do not have any requests coming to it.There are many such things we come across while troubleshooting in web farms.

Now as a performance engineer we can  find out which server is serving the request in the web farm by looking at the Miscellaneous headers of the response. These are the additional Custom headers which are normally configured to provide additional information to know as which servers are serving the request in the web farm or anything which we are looking for like asp.net version or jdk version etc. For IIS based web farms, below are some headers,

  • Server
  • X-Server
  • X-Powered-By
  • X-ASP.NET-Version

If you install the fiddler , you can see all these headers in the response header section of the response.X-Server is the header  which will tell you which sever in the farm is serving the request.The value associated with this header is the server which is serving the request.The fiddler trace will look something like below


If you look at the value of X-Server in above picture , its having value web303 which means  that response has be served from web303 box and this is IIS web server box by name WEB303.Also please understand that all these servers naming convention depends on your environment.So you need to check with your server admistrator for your server names.

I would also like highlight that not all web farms environment will have this setup for custom additional headers,if case if this setup is not available in your web farm,you can request your server admin to add custom these header.This is normally done using URL Rewrite Outbound Rules which can be done for most of the web servers available in the market like IIS and Apache.This process also do not have much processing overheads.

We can also have the scripted solution for this in our all Load testing scripts . Below is the LoadRunner code which will capture the value from the server response headers.

web_reg_save_param (“X-Server”,





All you need to do it to place this code at the top of the first request  and output the X-Server value in the log. Using this approach , I am sure you are going to save lot of time in troubleshooting your webservers in your web farm environment.

If you still have better ideas for web farms, go ahead and mail  me at kiran at vasanti.org

Tags: , , , , ,