Every team wants to reproduce a production like performance test so as the produce the maximum number of issues as could be observed in production environment. Running a production like performance test is as if every performance test manager’s dream. But it is no cake walk. To execute such a test, a lot of factors need to be taken into consideration and this is what happens in the planning phase. When an app goes live in production, it is the weblogs that keep a track of activities performed on the system by the end users. It records site’s traffic and load patterns. This information is obtained in the form of different metrics which in some form or other reside in the Web server logs. Some key metrics, which is very important from performance testing perspective and as can be obtained from web logs are –
Number of user sessions per unit time: When a user visits a site, the flow of business actions that he takes on the site occur in one session and is stored in web logs as a part of that session. If he doesn’t perform any step for some time (eg., 30 mins or so), his session expires and the actions he takes after a session expiry gets stored in another session.
Number of page views per unit time: A request when is fired on the server carry with itself many child requests which are dependent files on the page that is being requested for. Those files can be in the form of .css, .jpg files, etc. These separate files are considered and are tracked on the production systems. They give an idea about the number of hits happening on the server. Thus number of page views can be tracked per unit time.
Distribution of user modules: A user may have access to different modules in a system like ‘login’, ‘create ticket’, ‘edit dashboard’, etc. From the web logs the distribution percentage across different modules can be obtained and those can be used in determining the distribution of load across different modules in the system.
User exit time: It gives an information about the time the user will wait on the system before he receives an information and that will not make him leave the site. It depends upon every individual user’s individual expectation and his patience level. This information is extremely essential for product owners and project managers since they are the ones who have to take a decision while trading off ‘response time’ against ‘expense incurred to improve the same’.
Think time: When a user moves from one page to another, he waits on the first page thinks on what task he has to perform and then move to the next page. This is called think time or wait time. It is a very important concept and is very judiciously followed while developing scripts. After getting an average for all users (or distribution characteristics information), one can add the values in the script and make script and user scenario more production like.
Duration of session: Though the application development team may have put a hard stop session end time on the system, it is not necessary that users may remain on the system for the same amount of time. In some cases, users may complete all of their essential activities in the same time or in some other, they may take a break while working in a session and thus elongate the duration of a session. It is essential to gather this information about the duration of session. It helps not just the developers to set an appropriate session end time but also helps in planning a performance test well.
Thus getting the above information from weblogs or from any web analytics generating tool can be extremely helpful while designing the performance test. It not only helps in identifying the right performance test to go for but also helps in recognizing the ‘number of virtual users’, ‘think time values’, etc. to go for to design a production like performance test. Only a production like test can help in reproducing production like issues. Thus it is extremely essential to track and extract information from weblogs in order to design the best possible performance test.