Understanding Memory issues through Perfmon:Page faults

I have been using Perfmon almost daily, but never took pain to learn how to use it efficiently until I came across a situation …In this part we will discuss using perfmon to see memory bottleneck.
Before we proceed forward let us go through few definitions so that the rest of the stuff is easily understood.

Virtual memory: Its actually virtual …and from here the concept of paging comes in to picture .On a 32 bit machine its 2 gigs for user process by default ….So, if your RAM is 512 MB, the remaining stuff (I mean greater that 512 MB) that’s going to come from Virtual memory will page out to disk .SO operations worth 2 gigs will happen in VAS (VM) and as a storage RAM will be used and the moment RAM limit is exceeded …..Paging/Swapping .

Page: Committed data in VAS is written to Page tables .From there it goes to RAM or Pagefile .This data is written in to pages (in bytes) and its size is processor dependent. this page is fitted in to page frame in RAM…it is essential that , that frame must be filled with zeros before a page from disk is inserted into page frame .zeroing is essential as the page before zeroing may have information from any other process ..So when we restart Windows this zeroing activity takes place and complete by the virtual memory manager before the Windows comes up..And if there is some problem during zeroing then………….. :D …we will discuss some other time …

Page file: a space in the HDD to be used to save committed memory objects.

Reserved memory: the memory quota given to a process by the VM manager .So the process first has to consume this before the next quota is allocated …

Committed memory: The chunk from reserved memory that is actually being used by the process. Remember that whenever memory is committed the same amount of space is created on the pagefile so that if needed it can be flushed to disk.

Working Set: Physical memory assigned to a process by VM manager (or say OS).It will be always less than Private Bytes.

Page Fault : When the page needed is not found in the working set of the process but its with in the RAM (may be in some cache) its called as Soft page fault .But when the page is not at all found in the RAM , its paged out and called as Hard page fault.

So now, it’s sure that whenever there is a memory issue there will be high (hard) Page fault rate...If there is a constant high hard page fault rate it means that there is some data not found in the RAM for the working set of that process .So , it has to be fetched from the disk (which is going to be costly).And the hard page faults cause Paging .So is paging harmful ….No (we cannot avoid it ), but the excess of it is a signal that something is going wrong .Generally I have seen that keeping the page file to be equal to 1.5 times of RAM is ok ..Not bad.

In case of memory issue the counters that we need to see in Perfmon are Memory and Process...

The Sub counters for memory counter are: Page Faults/sec, Page Reads/sec, Page Writes/sec, Pages Input/sec, Pages Output/sec, Available bytes and nonpaged pool bytes.

The Sub counters for Process counter are: Page Faults/sec, working set, Private Bytes and Page File Bytes

So, % Soft page faults = ((Page fault/sec - Pages input/sec) x 100)/Page faults/sec

Now, if there are more hard page faults, there should be more pages output/sec (no of pages sent to disk to make room for the pages coming form disk due to hard page fault) since there is a limited working set and hence there has to be some space for the pages coming from the disk (hard page faults) ...Pages read/sec and pages input/sec should be almost similar but can be a bit different …So these counters can tell you the system story..One more counter that I forgot to mention is Available Bytes .Its the no. of bytes left for the process to allocate. To see how much SQL Server shares you can see Page Faults/sec and proportionate it with Total Page faults. Generally, hard page fault of 10% to 15% should be tolerated …Before, we totally blame memory let’s check the Disk performance as well...

Subtract Memory:Page reads/sec from logical disk:disk reads/sec .If the output is small (+ or -) then the memory is the bottleneck because this actually means that all the disk reading is done to find the faulting pages .Also if disk output/sec is high then you can check by finding the difference of disk output/sec and Disk write bytes/sec ÷ 4096 ßintel and fine its percentage in total Disk write bytes/sec

Similarly, you can then correlate it to SQL Server as well …..Once you are sure that memory is the bottleneck then we can proceed with the troubleshooting steps...
Next time we will try to dig into memory issues including memory leaks and also perfmon counters specific to SQL Server …

Web Page Rendering

Below are the step-by-step descriptions of how page get displayed in your browser when you simply enter some URL in address bar:

1.    You type an URL into address bar in your preferred browser.

2.    The browser parses the URL to find the protocol, host, port, and path.

3.    It forms a HTTP request

4.    To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookupon the host

5.    Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)

6.    When a connection is open, the HTTP request is sent to the host

7.    The host forwards the request to the server software (most often Apache) configured to listen on the specified port

8.    The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)

9.    The plugin gets access to the full request, and starts to prepare a HTTP response.

10.  To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request

11.  Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probablyHTML).

12.  The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to thebrowser.

13.  The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response

14.  A DOM tree is built out of the broken HTML

15.  New requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.

16.  Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree

17.  Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly

18.  The browser renders the page on the screen according to the DOM tree and the style information for each node

19.  You see the page on the screen 

Test Plan and Test Strategy

Test strategy:
This document is normally prepared by project manager using business requirement documents and is normally not updated frequently.

Test Plan:
This document is prepared by test lead or Senior Test engineer using SRS, use case document, product description. This is usually derived from test strategy. This document is updated with each release or build

Components of the Test Strategy document	Components of the Test Plan document
Scope and Objectives	Test Plan id
Business issues	Introduction
Roles and responsibilities	Test items
Communication and status reporting	Features to be tested
Test deliverability	Features not to be tested
Industry standards to follow	Test techniques
Test automation and tools	Testing tasks
Testing measurements and metrices	Suspension criteria
Risks and mitigation	Features pass or fail criteria
Defect reporting and tracking	Test environment (Entry criteria, Exit criteria)
Change and configuration management	Test delivarables
Training plan	Staff and training needs
	Responsibilities
	Schedule

Transactional Concurrency in Load testing

Problem - How many transaction will need to run per minute if a load test  has to run for 2 hours with 5000 users, assuming average length of transaction if 5 minutes.

Solution-
Duration of load test -120 minutes
User load- 5000
Average Length of transaction- 5 minutes
No. of transaction per minute-?


No. of transaction performed by single user in 120 minute = 120 minutes / 5 minute = 24 transaction

No. of transaction performed in 2 hours by 5000 users = 5000*24 =120000 transactions.

No. of transaction per minute =No. of transaction performed during 2 hour by 5000 users/duration of two hour = 120000/120= 1000 Transaction /Minute

LoadRunner : Save Dynamic Parameter value in Text File

I have a  value which dynamic for each iteration. I have captured that value using web_reg_save_param(correlation) function. Please any enahncement in the script is most welcome….

Action_Main_URL()

{

 char MainID; 

 int i; 

 char Length[100]; 

 long file; 

 char * filename = “c:\\Session.txt”; 

 if ((file = fopen(filename, “a+” )) == NULL) 

 { 

 lr_output_message(“Unable to create %s”, filename); 

 return -1; 

 }

 web_reg_save_param( “Cor_Session_Id”, “LB= value=’”, “RB=’”, “Ord=6″, “IgnoreRedirections=Yes”, “Search=Body”, “RelFrameId=1″, LAST );

 web_url(“Workplace”,

  ”URL=http://server/Workplace”,

  ”Resource=0″,

  ”RecContentType=text/html”,

  ”Referer=”,

  ”Snapshot=t1.inf”,

  ”Mode=HTML”,

  LAST);

 lr_start_transaction(“TS_Main_URL_Login”);

 web_reg_find(“Text=Record Search and Check-In”, “SaveCount=Value_Count”,

  LAST);

 web_submit_data(“WcmSignIn.jsp”,

  ”Action=http://server/Workplace/WcmSignIn.jsp?eventTarget=signInModule&eventName=SignIn”,

  ”Method=POST”,

  ”RecContentType=text/html”,

  ”Referer=http://server/Workplace/WcmSignIn.jsp?targetUrl=WcmDefault.jsp&targetBase=http%3A%2F%2Fserver%2FWorkplace&sessionId={Cor_Session_Id}&originIp=10.x.x.x&originPort=”,

  ”Snapshot=t2.inf”,

  ”Mode=HTML”,

  ITEMDATA,

  ”Name=targetBase”, “Value=http://server/Workplace”, ENDITEM,

  ”Name=originPort”, “Value=”, ENDITEM,

  ”Name=targetUrl”, “Value=Default.jsp”, ENDITEM,

  ”Name=encodedSessionId”, “Value=null”, ENDITEM,

  ”Name=originIp”, “Value=10.x.x.x”, ENDITEM,

  ”Name=sessionId”, “Value={Cor_Session_Id}”, ENDITEM,

  ”Name=browserTime1″, “Value=Sat Jan 1 05 EST 2011″, ENDITEM,

  ”Name=browserTime2″, “Value=Wed Jun 15 05 EDT 2011″, ENDITEM,

  ”Name=browserOffset1″, “Value=300″, ENDITEM,

  ”Name=browserOffset2″, “Value=240″, ENDITEM,

  ”Name=clientTimeZone”, “Value=”, ENDITEM,

  ”Name=appId”, “Value=Workplace”, ENDITEM,

  ”Name=userId”, “Value=userid”, ENDITEM,

  ”Name=password”, “Value=password”, ENDITEM,

  EXTRARES,

  ”Url=images/web/common/Banner.jpg”, “Referer=http://server/Workplace/HomePage.jsp?mode=reset”, ENDITEM,

  LAST);

 if (atoi(lr_eval_string(“{Value_Count}”)) > 0)

  {

  lr_output_message(“Page found successfully.”);

  }

  else

   {

   lr_error_message(“Page is not found.”);

   lr_exit( LR_EXIT_MAIN_ITERATION_AND_CONTINUE,LR_FAIL );

  return(0);

   }

 lr_end_transaction(“TS_Main_URL_Login”,LR_AUTO);

 sprintf(Length,”\n%s,”,lr_eval_string(“{Cor_Session_Id}”)); 

 i = fwrite(&Length,sizeof(Length), 1, file); 

 if ( i > 0) 

 lr_output_message(“Successfully wrote %d record”, i ); 

 fclose(file);

 return 0;

}

Loadrunner tutorial

Loadrunner Tutorial 1

Advanced Load Runner from telab

LoadRunner Tutorial 2

Loadrunner presentation from abc

Requirement Gathering for Performance test Project

Here are the Ideal Requirements to be included while developing a Performance test plan.

• Deadlines available to complete performance testing, including the scheduled deployment date.

• Whether to use internal or external resources to perform the tests. This will largely depend on time scales and in-house expertise (or lack thereof).

• Test environment design agreed upon. Remember that the test environment should be as close an approximation of the live environment as you can achieve and will require longer to create than you estimate.

• Ensuring that a code freeze applies to the test environment within each testing cycle.

• Ensuring that the test environment will not be affected by other user activity. Nobody else should be using the test environment while performance test execution is taking place; otherwise, there is a danger that the test execution and results may be compromised.

• All performance targets identified and agreed to by appropriate business stakeholders. This means consensus from all involved and interested parties on the performance targets for the application. 

• The key application transactions identified, documented, and ready to script. Remember how vital it is to have correctly identified the key transactions to script. Otherwise, your performance testing is in danger of becoming a wasted exercise.

• Which parts of transactions (such as login or time spent on a search) should be monitored separately. This will be used in Step 3 for “checkpointing.”

• Identify the input, target, and runtime data requirements for the transactions that you  select. This critical consideration ensures that the transactions you script run correctly and that the target database is realistically populated in terms of size and content. Data is critical to performance testing. Make sure that you can create enough test data of the correct type within the time frames of your testing project. You may need to look at some form of automated data management, and don’t forget to consider data security and confidentiality.

• Performance tests identified in terms of number, type, transaction content, and virtual user deployment. You should also have decided on the think time, pacing, and injection profile for each test transaction deployment.

• Identify and document server, application server, and network KPIs. Remember that you must monitor the application landscape as comprehensively as possible to ensure that you have the necessary information available to identify and resolve any problems that occur.

• Identify the deliverables from the performance test in terms of a report on the test’s outcome versus the agreed performance targets. It’s a good practice to produce a document template that can be used for this purpose.

• A procedure is defined for submission of performance defects discovered during testing cycles to the development or application vendor. This is an important consideration that is often overlooked. What happens if, despite your best efforts, you find major application, related problems? You need to build contingency into your test plan to accommodate this possibility. There may also be the added complexity of involving offshore resources in the defect submission process. If your plan is to carry out the performance testing in-house then you will also need to address the following points, relating to the testing team.

How to Define Pacing in Load Testing

 Pacing Calculation :-



 D = Duration of the test(test window/time frame)
 B = Baseline time(total time taken by 1 Vu to complete 1 whole iteration)

 T = Total amount of Think time in the script

 I = Expected/Target iteration

 R = Residual time of the test window.

 R = ( D - (T + B)*I)

 P = Pacing interval

 Dividing the residual time by target iteration gives pacing interval

Hence:
 P = R/I 


D is pacing time.
(T + B)*I represents the duration of a scenario
and P is the waiting time before the next scenario