How Domain Knowledge is important for a tester?

First of all I would like to introduce three dimensional testing career .There are three categories of skill that need to be judged before hiring any software tester. What are those three skill categories?
1) Testing skill
2) Domain knowledge
3) Technical expertise.

No doubt that any tester should have the basic testing skills like Manual testing and Automation testing. Tester having the common sense can even find most of the obvious bugs in the software. Then would you say that this much testing is sufficient? Would you release the product on the basis of this much testing done? Certainly not.You will certainly have a product look by the domain expert before the product goes into the market.

While testing any application you should think like a end-user. But every human being has the limitations and one can’t be the expert in all of the three dimensions mentioned above. (If you are the experts in all of the above skills then please let me know ;-)) So you can’t assure that you can think 100% like how the end-user going to use your application. User who is going to use your application may be having a good understanding of the domain he is working on. You need to balance all these skill activities so that all product aspects will get addressed.

Nowadays you can see the professional being hired in different companies are more domain experts than having technical skills. Current software industry is also seeing a good trend that many professional developers and domain experts are moving into software testing.

We can observe one more reason why domain experts are most wanted! When you hire fresh engineers who are just out of college you cannot expect them to compete with the experienced professionals. Why? Because experienced professional certainly have the advantage of domain and testing experience and they have better understandings of different issues and can deliver the application better and faster.

Here are some of the examples where you can see the distinct edge of domain knowledge:
1) Mobile application testing.
2) Wireless application testing
3) VoIP applications
4) Protocol testing
5) Banking applications
6) Network testing

How will you test such applications without knowledge of specific domain? Are you going to test the BFSI applications (Banking, Financial Services and Insurance) just for UI or functionality or security or load or stress? You should know what are the user requirements in banking, working procedures, commerce background, exposure to brokerage etc and should test application accordingly, then only you can say that your testing is enough - Here comes the need of subject-matter experts.

Let’s take example of my current project: I am currently working on a project based on E-learning and which is a complete LMS (Learning Management System). If a tester do not have the domain knowledge or if he doesn't know what is "assessments" , "standards" and "prescription" , then how can he test that application.

When I know the functional domain better I can better write and execute more test cases and can effectively simulate the end user actions which is distinctly a big advantage.

Here is the big list of the required testing knowledge:

• Testing skill 
• Bug hunting skill 
• Technical skill 
• Domain knowledge 
• Communication skill 
• Automation skill 
• Some programming skill 
• Quick grasping 
• Ability to Work under pressure … 

That is going to be a huge list. So you will certainly say, do I need to have these many skills? Its’ depends on you. You can stick to one skill or can be expert in one skill and have good understanding of other skills or balanced approach of all the skills. This is the competitive market and you should definitely take advantage of it. Make sure to be expert in at least one domain before making any move.

What if you don’t have enough domain knowledge?
You will be posted on any project and company can assign any work to you. Then what if you don’t have enough domain knowledge of that project? You need to quickly grasp as many concepts as you can. Try to understand the product as if you are the customer and what customer will do with application. Visit the customer site if possible know how they work with the product, Read online resources about the domain you want to test the application, participate in events addressing on such domain, meet the domain experts. Or either company will provide all this in-house training before assigning any domain specific task to testers.

There is no specific stage where you need this domain knowledge. You need to apply your domain knowledge in each and every software testing life cycle.

If there are no requirements, how will you write your test plan?

If there are no requirements we try to gather as much details as possible from:

• Business Analysts
• Developers (If accessible)
• Previous Version documentation (if any)
• Stake holders (If accessible)
• Prototypes

How to calculate sessions per hour in performance testing? - Little's Law

Calculating Sessions per hour: For this discussion, we will be focusing on a session as the total time for the user group to finish one complete set of transactions. We may wish to know the number sessions that will be completed for any given number of virtual users. 

Example 1:- If a baseline test shows that a User Type takes a total of 120 seconds for a session, then in an hour long steady state test this User Type should be able to complete 3600 / 120 = 30 sessions per hour. Twenty of these users will complete 20 x 30 = 600 of these session in an hour. In other cases, we have a set number of sessions we want to complete during the test and want to determine the number of virtual users to start. 

Example 2:Using the same conditions in our first example, if our target session rate for sessions per hour is 500, then 500 / 30 = 16.7 or 17 virtual users. A formula called Little's Law states this calculation of Virtual Users in slightly different terms.

Using Little's Law with Example 2:

V.U. = R x D 

where R = Transaction Rate and

D = Duration of the Session

If our target rate is 500 sessions per hour (.139 sessions/sec) and our duration is 120 seconds, then Virtual Users = .139 x 120 = 16.7 or 17 virtual users.

Case Studies – Identifying Performance-testing Objectives

Case Study 1 Scenario

A 40-year-old financial services company with 3,000 employees is implementing its annual Enterprise Resource Planning (ERP) software upgrade, including new production hardware. The last upgrade resulted in disappointing performance and many months of tuning during production.

Performance Objectives

The performance-testing effort was based on the following overall performance objectives:
Ensure that the new production hardware is no slower than the previous release.
Determine configuration settings for the new production hardware.
Tune customizations. 

Performance Budget/Constraints

The following budget limitations constrained the performance-testing effort:
No server should have sustained processor utilization above 80 percent under any anticipated load. (Threshold)
No single requested report is permitted to lock more than 20 MB of RAM and 15-percent processor utilization on the Data Cube Server.
No combination of requested reports is permitted to lock more than 100 MB of RAM and 50-percent processor utilization on the Data Cube Server at one time. 

Performance-Testing Objectives

The following priority objectives focused the performance testing:
Verify that there is no performance degradation over the previous release.
Verify the ideal configuration for the application in terms of response time, throughput, and resource utilization.
Resolve existing performance inadequacy with the Data Cube Server.

Questions

1. The following questions helped to determine relevant testing objectives: 
2. What is the reason for deciding to test performance? 
3. In terms of performance, what issues concern you most in relation to the upgrade? 
4. Why are you concerned about the Data Cube Server? 

Case Study 2
Scenario

A financial institution with 4,000 users distributed among the central headquarters and several branch offices is experiencing performance problems with business applications that deal with loan processing.
Six major business operations have been affected by problems related to slowness as well as high resource consumption and error rates identified by the company’s IT group. The consumption issue is due to high processor usage in the database, while the errors are related to database queries with exceptions.

Performance Objectives

• The performance-testing effort was based on the following overall performance objectives: 
• The system must support all users in the central headquarters and branch offices who use the system during peak business hours. 
• The system must meet backup duration requirements for the minimal possible timeframe. 
• Database queries should be optimal, resulting in processor utilization no higher than 50-75 percent during normal and peak business activities. 

Performance Budget/Constraints

The following budget limitations constrained the performance-testing effort:

• No server should have sustained processor utilization above 75 percent under any anticipated load (normal and peak) when users in headquarters and branch offices are using the system. (Threshold) 
• When system backups are being performed, the response times of business operations should not exceed 8 percent, or the response times experienced when no backup is being done. 
• Response times for all business operations during normal and peak load should not exceed 6 seconds. 
• No error rates are allowable during transaction activity in the database that may result in the loss of user-submitted loan applications. 

Performance-Testing Objectives

The following priority objectives focused the performance testing:

• Help to optimize the loan-processing applications to ensure that the system meets stated business requirements. 
• Test for 100-percent coverage of the entire six business processes affected by the loan-manufacturing applications. 
• Target database queries that were confirmed to be extremely sub-optimal, with improper hints and nested sub-query hashing. 
• Help to remove superfluous database queries in order to minimize transactional cost. 
• Tests should monitor for relevant component metrics: end-user response time, error rate, database transactions per second, and overall processor, memory, network, and disk status for the database server. 

Questions

1. The following questions helped to determine relevant testing objectives: 
2. What is the reason for deciding to test performance? 
3. In terms of performance, what issues concern you most in relation to the queries that may be causing processor bottlenecks and transactional errors? 
4. What business cases related to the queries might be causing processor and transactional errors? 
5. What database backup operations might affect performance during business operations? 
6. What are the timeframes for back-up procedures that might affect business operations, and what are the most critical scenarios involved in the time frame? 
7. How many users are there and where are they located (headquarters, branch offices) during times of critical business operations? 

These questions helped performance testers identify the most important concerns in order to help prioritize testing efforts. The questions also helped determine what information to include in conversations and reports.

Case Study 3
Scenario
A Web site is responsible for conducting online surveys with 2 million users in a one-hour timeframe. The site infrastructure was built with wide area network (WAN) links all over the world. The site administrators want to test the site’s performance to ensure that it can sustain 2 million user visits in one hour. 

Performance Objectives

The performance-testing effort was based on the following overall performance objectives:
The Web site is able to support a peak load of 2million user visits in a one-hour timeframe.
Survey submissions should not be compromised due to application errors. 

Performance Budget/Constraints

The following budget limitations constrained the performance-testing effort:
No server can have sustained processor utilization above 75 percent under any anticipated load (normal and peak) during submission of surveys (2 million at peak load).
Response times for all survey submissions must not exceed 8 seconds during normal and peak loads.
No survey submissions can be lost due to application errors. 

Performance-Testing Objectives

The following priority objectives focused the performance testing:

• Simulate one user transaction scripted with 2 million total virtual users in one hour distributed among two datacenters, with 1 million active users at each data center. 
• Simulate the peak load of 2 million user visits in a one-hour period. 
• Test for 100-percent coverage of all survey types. 
• Monitor for relevant component metrics: end-user response time, error rate, database transactions per second, and overall processor, memory, network and disk status for the database server. 
• Test the error rate to determine the reliability metrics of the survey system. 
• Test by using firewall and load-balancing configurations.

Questions

1. The following questions helped to determine relevant testing objectives: 
2. What is the reason for deciding to test performance? 
3. In terms of performance, what issues concern you most in relation to survey submissions that might cause data loss or user abandonment due to slow response time? 
4. What types of submissions need to be simulated for surveys related to business requirements? 
5. Where are the users located geographically when submitting the surveys?

Test Strategy Vs Test Planning

Test Strategy:

A Test Strategy document is a high level document and normally developed by project manager. This document defines “Testing Approach” to achieve testing objectives. The Test Strategy is normally derived from the Business Requirement Specification document(BRS).

The Test Stategy document is a static document meaning that it is not updated too often. It sets the standards for testing processes and activities and other documents such as the Test Plan draws its contents from those standards set in the Test Strategy Document.
Some companies include the “Test Approach” or “Strategy” inside the Test Plan, which is fine and it is usually the case for small projects. However, for larger projects, there is one Test Strategy document and different number of Test Plans for each phase or level of testing.

Components of the Test Strategy document :

• Scope and Objectives 
• Business issues 
• Roles and responsibilities 
• Communication and status reporting 
• Test deliverability 
• Industry standards to follow 
• Test automation and tools 
• Testing measurements and metrices 
• Risks and mitigation 
• Defect reporting and tracking 
• Change and configuration management 
• Training plan 

Test Plan:

The Test Plan document on the other hand, is derived from the Product Description, Software Requirement Specification(SRS), or Use Case Documents.

The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.
It is not uncommon to have one Master Test Plan which is a common document for the test phases and each test phase have their own Test Plan documents.

There is much debate, as to whether the Test Plan document should also be a static document like the Test Strategy document mentioned above or should it be updated every often to reflect changes according to the direction of the project and activities.

My own personal view is that when a testing phase starts and the Test Manager is “controlling” the activities, the test plan should be updated to reflect any deviation from the original plan. After all, Planning and Control are continuous activities in the formal test process. 

Components of the Test Strategy document :

• Test Plan id 
• Introduction 
• Test items 
• Features to be tested 
• Features not to be tested 
• Test techniques 
• Testing tasks 
• Suspension criteria 
• Features pass or fail criteria 
• Test environment (Entry criteria, Exit criteria) 
• Test delivarables 
• Staff and training needs 
• Responsibilities 
• Schedule 

This is a standard approach to prepare test plan and test strategy documents, but things can vary company-to-company

Factors Affecting Performance of web application

It has been known for years that although software development constantly strives towards constant improvement, it will never completely be 100% perfect. An application’s performance, in turn, can only be as good as in comparison to its performance objectives.

Performance problems affect all types of systems, regardless of whether they are client/server or Web application systems. It is imperative to understand the factors affecting system performance before embarking on the task of handling them.

Generally speaking, the factors affecting performance may be divided into two large categories: project management oriented and technical.
Project Management Factors Affecting Performance In the modern Software Development Life Cycle (SDLC), the main phases are subject to time constraints in order to address ever growing competition.

This causes the following project management issues to arise:

•  Shorter coding time in development may lead to a lower quality product due to a lack of concentration on performance.
•  Chances of missing information due to the rapid approach may disqualify the performance objectives.
•  Inconsistent internal designs may be observed after product deployment, for example, too much cluttering of objects and sequence of screen navigation.
• Higher probability of violating coding standards, resulting in unoptimized code that may consume too many resources.
•  Module reuse for future projects may not be possible due to the project specific design.
• Module may not be designed for scalability.
• System may collapse due to a sudden increase in user load.

Technical Factors Affecting Performance
While project management related issues have great impact on the output, technical problems may severely affect the application’s overall performance. The problems may stem from the selection of the technology platform, which may be designed for a specific purpose and does not perform well under different conditions.

Usually, however, the technical problems arise due to the developer’s negligence regarding performance. A common practice among many developers is not to optimize the code at the development stage. This code may unnecessarily utilize scarce system resources such as memory and processor. Such coding practice may lead to severe performance bottlenecks
such as:

• memory leaks
• array bound errors
• inefficient buffering
• too many processing cycles
• larger number of HTTP transactions
• too many file transfers between memory and disk
• inefficient session state management
• thread contention due to maximum concurrent users
• poor architecture sizing for peak load
• inefficient SQL statements
• lack of proper indexing on the database tables

inappropriate configuration of the servers

These problems are difficult to trace once the code is packaged for deployment and require special tools and methodologies. Another cluster of technical factors affecting performance is security.
Performance of the application and its security are commonly at odds, since adding layers of security (SSL, private/public keys and so on) is extremely computation intensive. Network related issues must also be taken into account, especially with regard to Web applications. They may be coming from the various sources such as:

•  Older or unoptimized network infrastructure
• Slow web site connections lead to network traffic and hence poor response time
• Imbalanced load on servers affecting the performance

Performance Testing Estimation Preparation

It depends of which estimation techniue you are using...if it is WBS then you will have to break all the performance testing activities in smaller parts then using your prior experience you can estimate no of days for each activities. Also take some time for each activity in spare so that you can get time in case of any environmental or deploymental delay or issue. Incase of WBS following activities can be considered:

A. Planning
1. Understanding of application
2. Identifing of NFR
3. Finilazing the workload model
4. setup of test environment and tools& monitors
5. Preperation of Test plan

B. Preperation
1. Creation & validation of Test scripts
2. Creation of Test Data
3. Creation of business scenarios
4. Getting approval

C. Execution
1.Run a dummy test
2. Baseline test
3. Upgrade or tune the environment (if needed)
4. baseline test2
5. final performance run
6. Analysis
7. Final performance run2
8. Benchmarking etc..

D. Reporting
1. Creation of performance test report
2. Review with seniors or peers
3. Update the report
4. Publish the final report.
5. Getting signoff

Why response time of a page does not equal the sum of its requests

The response time for a page typically differs from the sum of its requests. This does not mean that your data is incorrect. The difference can be caused by concurrent requests, page connection times, inter-request delays, and custom code within a page.

The most common reason for the sum of the individual request times within a page to exceed the total page response time is that requests are often sent concurrently (in parallel) to a server. Thus some of the individual request response times overlap so the sum of the request response times would exceed the page response time.

Additionally, the page response time can exceed the sum of the individual request response times within the page for the following reasons:

• The individual request response times do not include time to establish connections but the page response time does include the connection request time. 
• Inter-request delays are not reflected in the individual request response time but are reflected in the page response time. 
• Custom code placed within a page is executed serially (after waiting for all previous individual requests to complete) and thus contributes to the page response time. It does not affect individual request response times. However, we recommend that you place custom code outside of a page, where it will not affect page response time.

Transactional Concurrency in Load testing

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

Write data to an external file in load runner | Save Dynamic Parameters into a Text File using load runner

I got a requirement of capturing dynamic values and write it to a notepad file using load runner vugen. Here is the code snippet i have tried and worked well. i captured the order ids and I stored in local file and provided them dev team later for easy debug. Here is the code snippet.

Action()

{

char MainID;

int i;

char Length[100];

long file;

// This is to create the file for writing order IDs

char * filename = "C:\\Users\\Raviteja\\Downloads\\OredrID.txt";

//Open file with Read Permission

if ((file = fopen(filename, "a+" )) == NULL)

{

lr_output_message("Unable to create %s", filename);

return -1;

}

web_reg_save_param("OrderID","LB=value=’","RB=’/","RelFrameId=1″,LAST);

web_url("HondaCity",

"URL=https://Mynewhondacity.com/Homepage#",

"Resource=0″,

"RecContentType=text/html",

"Referer=",

"Snapshot=t1.inf",

"Mode=HTML",

LAST);

web_reg_find("Text=This Order is created","SaveCount=OrderIDCount",LAST);

lr_start_transaction("Digital_HondaCity_01_OrderID");

web_submit_data("mycar.jsp",

"Action=https://Mynewhondacity.com/GenerateOrder/Valuenumber",

"Method=POST",

"RecContentType=text/html",

"Referer=https://Mynewhondacity.com/GenerateOrder/",

"Snapshot=t2.inf",

"Mode=HTML",

ITEMDATA,

"Name=sessionId", "Value={OrderID}", 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=WorkHondatwin", ENDITEM,

"Name=userId", "Value=Zelensky", ENDITEM,

"Name=password", "Value=Strawberry@123", ENDITEM,

LAST);

if (atoi(lr_eval_string("{OrderIDCount}")) > 0)

{

lr_output_message("Orders Page found and loaded successfully.");

}

else

{

lr_error_message("Orders Page is not found.");

lr_exit( LR_EXIT_MAIN_ITERATION_AND_CONTINUE,LR_FAIL );

return(0);

}

lr_end_transaction("Digital_HondaCity_01_OrderID",LR_AUTO);

//Writing the values into the file

sprintf(Length,"\n%s,",lr_eval_string("{OrderID}"));

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

if ( i > 0)

lr_output_message("Order Ids written successfully to the file %d records", i );

fclose(file);

return 0;

}

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.

Important aspects of Performance test project

Important aspects of a Performance test project
For a performance testing project to be successful, both the approach to testing performance and the testing itself must be relevant to the context of the project. Without an understanding of the project context, performance testing is bound to focus on only those items that the performance tester or test team assumes to be important, as opposed to those that truly are important, frequently leading to wasted time, frustration, and conflicts.

The project context is nothing more than those things that are, or may become, relevant to achieving project success. This may include, but is not limited to:

• The overall vision or intent of the project 
• Performance testing objectives 
• Performance success criteria 
• The development life cycle 
• The project schedule 
• The project budget 
• Available tools and environments set of the 
• The skill performance tester and the team 
• The priority of detected performance concerns 
• The business impact of deploying an application that performs poorly 

Some examples of items that may be relevant to the performance-testing effort in your project context include:
Project vision: Before beginning performance testing, ensure that you understand the current project vision. The project vision is the foundation for determining what performance testing is necessary and valuable. Revisit the vision regularly, as it has the potential to change as well.
Purpose of the system: Understand the purpose of the application or system you are testing. This will help you identify the highest-priority performance characteristics on which you should focus your testing. You will need to know the system’s intent, the actual hardware and software architecture deployed, and the characteristics of the typical end user.
Customer or user expectations. Keep customer or user expectations in mind when planning performance testing. Remember that customer or user satisfaction is based on expectations, not simply compliance with explicitly stated requirements.
Business drivers: Understand the business drivers – such as business needs or opportunities – that are constrained to some degree by budget, schedule, and/or resources. It is important to meet your business requirements on time and within the available budget.
Reasons for testing performance. Understand the reasons for conducting performance testing very early in the project. Failing to do so might lead to ineffective performance testing. These reasons often go beyond a list of performance acceptance criteria and are bound to change or shift priority as the project progresses, so revisit them regularly as you and your team learn more about the application, its performance, and the customer or user.
Value that performance testing brings to the project. Understand the value that performance testing is expected to bring to the project by translating the project- and business-level objectives into specific, identifiable, and manageable performance testing activities. Coordinate and prioritize these activities to determine which performance testing activities are likely to add value.
Project management and staffing:Understand the team’s organization, operation, and communication techniques in order to conduct performance testing effectively.
Process. Understand your team’s process and interpret how that process applies to performance testing. If the team’s process documentation does not address performance testing directly, extrapolate the document to include performance testing to the best of your ability, and then get the revised document approved by the project manager and/or process engineer.
Compliance criteria: Understand the regulatory requirements related to your project. Obtain compliance documents to ensure that you have the specific language and context of any statement related to testing, as this information is critical to determining compliance tests and ensuring a compliant product. Also understand that the nature of performance testing makes it virtually impossible to follow the same processes that have been developed for functional testing.
Project schedule: Be aware of the project start and end dates, the hardware and environment availability dates, the flow of builds and releases, and any checkpoints and milestones in the project schedule.

Difference between Application server and Web server ?

A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.

The Web server:
A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser. 

Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.

While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers. 

The application server:
As for the application server, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world). 

Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.

In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.

Lets see the below example:

As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function. 

Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.

Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.

In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.

By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page. To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

Note:Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.
Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

LR function web_reg_save_param(); in load runner(detailed description)

This function registers a request to save dynamic data information to a parameter.

Syntax for C language:

int web_reg_save_param( const char *ParamName, <List of Attributes>, LAST );

Syntax for Java language:

int object.reg_save_param( String ParamName, String[] attributeList );

The web_reg_save_param function is a Service function used for correlating HTML statements in Web scripts..

Object :An expression evaluating to an object of type WebApi. Usually web for Java and Visual Basic. See also Function and Constant Prefixes.

ParamName : A null–terminated string indicating the name of the parameter to create.

List of Attribute : Attribute value strings (e.g., "Search=all") are not case–sensitive.

LAST :A marker that indicates the end of the argument list.

Note: (Service functions : Service Functions perform customization tasks, like setting of proxies, authorization information, user–defined headers and so forth. These functions do not make any change in the Web application context.

Many of the service functions specify run–time settings for a script. A setting that is set with a service function always overrides the corresponding setting set with the Run–time settings dialog box.)

General Information
web_reg_save_param is a registration type function. It registers a request to find and save a text string within the server response. The operation is performed only after executing the next action function, such as web_url.

web_reg_save_param is only recorded when correlation during recording is enabled (see VuGen's Recording Options). VuGen must be in either URL–based recording mode, or in HTML–based recording mode with the A script containing explicit URLs only option checked (see VuGen's Recording Options).

This function registers a request to retrieve dynamic information from the downloaded page, and save it to a parameter. For correlation, enclose the parameter in braces (e.g., "{param1}") in ensuing function calls which use the dynamic data. The request registered byweb_reg_save_param looks for the characters between (but not including) the specified boundaries and saves the information that begins at the byte after the left boundary and ends at the byte before the right boundary.

If you expect leading and trailing spaces around the string and you do not want them in the parameter, add a space at the end of the left boundary, and at the beginning of the right boundary. For example, if the Web page contains the string, "Where and when do you want to travel?", the call:

web_reg_save_param("When_Txt", "LB=Where and ", "RB= do",LAST );

Wth a space after "and" and before "do", will result in "when" as the value of When_Txt. However,

web_reg_save_param("When_Txt", "LB=Where and", "RB=do",LAST );

without the spaces, will result in a value of " when ".

Embedded boundary characters are not supported. web_reg_save_param results in a simple search for the next occurrence after the most recent left boundary. For example, if you have defined the left boundary as the character `{` and the right boundary as the character `}', then with the following buffer c is saved:

{a{b{c}

The left and right boundaries have been located. Since embedded boundaries are not supported, the `}' is matched to the most recent `{` appearing just before the c. The ORD attribute is 1. There is only one matching instance.

The web_reg_save_param function also supports array type parameters. When you specify ORD=All, all the occurrences of the match are saved in an array. Each element of the array is represented by the ParamName_index. In the following example, the parameter name is A:

web_reg_save_param("A", "LB/ic=", "Ord=All", LAST );

The first match is saved as A_1, the second match is saved as A_2, and so forth. You can retrieve the total number of matches by using the following term: ParamName_count. For example, to retrieve the total number of matches saved to the parameter array, use:

TotalNumberOfMatches=atoi(lr_eval_string("{A_count}"));

This function is supported for all Web scripts, and for WAP scripts running in HTTP or Wireless Session Protocol (WSP) replay mode.

List of Attributes
Convert: The possible values are:
HTML_TO_URL: convert HTML–encoded data to a URL–encoded data format
HTML_TO_TEXT: convert HTML–encoded data to plain text format
This attribute is optional.

IgnoreRedirections: If "IgnoreRedirections=Yes" is specified and the server response is redirection information (HTTP status code 300-303, 307), the response is not searched. Instead, after receiving a redirection response, the GET request is sent to the redirected location and the search is performed on the response from that location.
This attribute is optional. The default is "IgnoreRedirections=No".

LB: The left boundary of the parameter or the dynamic data. If you do not specify an LB value, it uses all of the characters from the beginning of the data as a boundary. Boundary parameters are case–sensitive and do not support regular expressions. To further customize the search text, use one or more text flags. This attribute is required. See the Boundary Arguments section.

NOTFOUND: The handling option when a boundary is not found and an empty string is generated.
"Notfound=error", the default value, causes an error to be raised when a boundary is not found.
"Notfound=warning" ("Notfound=empty" in earlier versions), does not issue an error. If the boundary is not found, it sets the parameter count to 0, and continues executing the script. The "warning" option is ideal if you want to see if the string was found, but you do not want the script to fail.
Note: If Continue on Error is enabled for the script, then even when NOTFOUND is set to "error", the script continues when the boundary is not found, but an error message is written to the Extended log file.
This attribute is optional.

ORD: Indicates the ordinal position or instance of the match. The default instance is 1. If you specify "All," it saves the parameter values in an array. This attribute is optional.
Note: The use of Instance instead of ORD is supported for backward compatibility, but deprecated.

RB: The right boundary of the parameter or the dynamic data. If you do not specify an RB value, it uses all of the characters until the end of the data as a boundary. Boundary parameters are case–sensitive and do not support regular expressions. To further customize the search text, use one or more text flags. This attribute is required. See the Boundary Arguments section.

RelFrameID: The hierarchy level of the HTML page relative to the requested URL. The possible values are ALL or a number. Click RelFrameID Attribute for a detailed description. This attribute is optional.
Note: RelFrameID is not supported in GUI level scripts.

SaveLen: The length of a sub–string of the found value, from the specified offset, to save to the parameter. This attribute is optional. The default is –1, indicating to save to the end of the string.

SaveOffset: The offset of a sub–string of the found value, to save to the parameter. The offset value must be non–negative. The default is 0. This attribute is optional. 

Search: The scope of the search—where to search for the delimited data. The possible values are Headers (Search only the headers), Body (search only body data, not headers), Noresource (search only the HTML body, excluding all headers and resources), or ALL (search body , headers, and resources). The default value is ALL. This attribute is optional.

Use Perfmon to monitor servers and find bottlenecks

What and When to Measure

Bottlenecks occur when a resource reaches its capacity, causing the performance of the entire system to slow down. Bottlenecks are typically caused by insufficient or misconfigured resources, malfunctioning components, and incorrect requests for resources by a program.

There are five major resource areas that can cause bottlenecks and affect server performance: physical disk, memory, process, CPU, and network. If any of these resources are overutilized, your server or application can become noticeably slow or can even crash. I will go through each of these five areas, giving guidance on the counters you should be using and offering suggested thresholds to measure the pulse of your servers.

Since the sampling interval has a significant impact on the size of the log file and the server load, you should set the sample interval based on the average elapsed time for the issue to occur so you can establish a baseline before the issue occurs again. This will allow you to spot any trend leading to the issue.

Fifteen minutes will provide a good window for establishing a baseline during normal operations. Set the sample interval to 15 seconds if the average elapsed time for the issue to occur is about four hours. If the time for the issue to occur is eight hours or more, set the sampling interval to no less than five minutes; otherwise, you will end up with a very large log file, making it more difficult to analyze the data.

Hard Disk Bottleneck

Since the disk system stores and handles programs and data on the server, a bottleneck affecting disk usage and speed will have a big impact on the server’s overall performance.

Please note that if the disk objects have not been enabled on your server, you need to use the command-line tool Diskperf to enable them. Also, note that % Disk Time can exceed 100 percent and, therefore, I prefer to use % Idle Time, Avg. Disk sec/Read, and Avg. Disk sec/write to give me a more accurate picture of how busy the hard disk is. You can find more on % Disk Time in the Knowledge Base article available at support.microsoft.com/kb/310067.

Following are the counters the Microsoft Service Support engineers rely on for disk monitoring.

LogicalDisk\% Free Space This measures the percentage of free space on the selected logical disk drive. Take note if this falls below 15 percent, as you risk running out of free space for the OS to store critical files. One obvious solution here is to add more disk space.

PhysicalDisk\% Idle Time This measures the percentage of time the disk was idle during the sample interval. If this counter falls below 20 percent, the disk system is saturated. You may consider replacing the current disk system with a faster disk system.

PhysicalDisk\Avg. Disk Sec/Read This measures the average time, in seconds, to read data from the disk. If the number is larger than 25 milliseconds (ms), that means the disk system is experiencing latency when reading from the disk. For mission-critical servers hosting SQL Server®and Exchange Server, the acceptable threshold is much lower, approximately 10 ms. The most logical solution here is to replace the current disk system with a faster disk system.

PhysicalDisk\Avg. Disk Sec/Write This measures the average time, in seconds, it takes to write data to the disk. If the number is larger than 25 ms, the disk system experiences latency when writing to the disk. For mission-critical servers hosting SQL Server and Exchange Server, the acceptable threshold is much lower, approximately 10 ms. The likely solution here is to replace the disk system with a faster disk system.

PhysicalDisk\Avg. Disk Queue Length This indicates how many I/O operations are waiting for the hard drive to become available. If the value here is larger than the two times the number of spindles, that means the disk itself may be the bottleneck.

Memory\Cache Bytes This indicates the amount of memory being used for the file system cache. There may be a disk bottleneck if this value is greater than 300MB.

Memory Bottleneck

A memory shortage is typically due to insufficient RAM, a memory leak, or a memory switch placed inside the boot.ini. Before I get into memory counters, I should discuss the /3GB switch.

More memory reduces disk I/O activity and, in turn, improves application performance. The /3GB switch was introduced in Windows NT® as a way to provide more memory for the user-mode programs.

Windows uses a virtual address space of 4GB (independent of how much physical RAM the system has). By default, the lower 2GB are reserved for user-mode programs and the upper 2GB are reserved for kernel-mode programs. With the /3GB switch, 3GB are given to user-mode processes. This, of course, comes at the expense of the kernel memory, which will have only 1GB of virtual address space. This can cause problems because Pool Non-Paged Bytes, Pool Paged Bytes, Free System Page Tables Entries, and desktop heap are all squeezed together within this 1GB space. Therefore, the /3GB switch should only be used after thorough testing has been done in your environment.

This is a consideration if you suspect you are experiencing a memory-related bottleneck. If the /3GB switch is not the cause of the problems, you can use these counters for diagnosing a potential memory bottleneck.

Memory\% Committed Bytes in Use This measures the ratio of Committed Bytes to the Commit Limit—in other words, the amount of virtual memory in use. This indicates insufficient memory if the number is greater than 80 percent. The obvious solution for this is to add more memory.

Memory\Available Mbytes This measures the amount of physical memory, in megabytes, available for running processes. If this value is less than 5 percent of the total physical RAM, that means there is insufficient memory, and that can increase paging activity. To resolve this problem, you should simply add more memory.

Memory\Free System Page Table Entries This indicates the number of page table entries not currently in use by the system. If the number is less than 5,000, there may well be a memory leak.

Memory\Pool Non-Paged Bytes This measures the size, in bytes, of the non-paged pool. This is an area of system memory for objects that cannot be written to disk but instead must remain in physical memory as long as they are allocated. There is a possible memory leak if the value is greater than 175MB (or 100MB with the /3GB switch). A typical Event ID 2019 is recorded in the system event log.

Memory\Pool Paged Bytes This measures the size, in bytes, of the paged pool. This is an area of system memory used for objects that can be written to disk when they are not being used. There may be a memory leak if this value is greater than 250MB (or 170MB with the /3GB switch). A typical Event ID 2020 is recorded in the system event log.

Memory\Pages per Second This measures the rate at which pages are read from or written to disk to resolve hard page faults. If the value is greater than 1,000, as a result of excessive paging, there may be a memory leak.

Processor Bottleneck

An overwhelmed processor can be due to the processor itself not offering enough power or it can be due to an inefficient application. You must double-check whether the processor spends a lot of time in paging as a result of insufficient physical memory. When investigating a potential processor bottleneck, the Microsoft Service Support engineers use the following counters.

Processor\% Processor Time This measures the percentage of elapsed time the processor spends executing a non-idle thread. If the percentage is greater than 85 percent, the processor is overwhelmed and the server may require a faster processor.

Processor\% User Time This measures the percentage of elapsed time the processor spends in user mode. If this value is high, the server is busy with the application. One possible solution here is to optimize the application that is using up the processor resources.

Processor\% Interrupt Time This measures the time the processor spends receiving and servicing hardware interruptions during specific sample intervals. This counter indicates a possible hardware issue if the value is greater than 15 percent.

System\Processor Queue Length This indicates the number of threads in the processor queue. The server doesn’t have enough processor power if the value is more than two times the number of CPUs for an extended period of time.

Network Bottleneck

A network bottleneck, of course, affects the server’s ability to send and receive data across the network. It can be an issue with the network card on the server, or perhaps the network is saturated and needs to be segmented. You can use the following counters to diagnosis potential network bottlenecks.

Network Interface\Bytes Total/Sec This measures the rate at which bytes are sent and received over each network adapter, including framing characters. The network is saturated if you discover that more than 70 percent of the interface is consumed. For a 100-Mbps NIC, the interface consumed is 8.7MB/sec (100Mbps = 100000kbps = 12.5MB/sec* 70 percent). In a situation like this, you may want to add a faster network card or segment the network.

Network Interface\Output Queue Length This measures the length of the output packet queue, in packets. There is network saturation if the value is more than 2. You can address this problem by adding a faster network card or segmenting the network.

Process Bottleneck

Server performance will be significantly affected if you have a misbehaving process or non-optimized processes. Thread and handle leaks will eventually bring down a server, and excessive processor usage will bring a server to a crawl. The following counters are indispensable when diagnosing process-related bottlenecks.

Process\Handle Count This measures the total number of handles that are currently open by a process. This counter indicates a possible handle leak if the number is greater than 10,000.

Process\Thread Count This measures the number of threads currently active in a process. There may be a thread leak if this number is more than 500 between the minimum and maximum number of threads.

Process\Private Bytes This indicates the amount of memory that this process has allocated that cannot be shared with other processes. If the value is greater than 250 between the minimum and maximum number of threads, there may be a memory leak.

Wrapping Up

Now you know what counters the Service Support engineers at Microsoft use to diagnose various bottlenecks. Of course, you will most likely come up with your own set of favorite counters tailored to suit your specific needs. You may want to save time by not having to add all your favorite counters manually each time you need to monitor your servers. Fortunately, there is an option in the Performance Monitor that allows you to save all your counters in a template for later use.

You may still be wondering whether you should run Performance Monitor locally or remotely. And exactly what will the performance hit be when running Performance Monitor locally? This all depends on your specific environment. The performance hit on the server is almost negligible if you set intervals to at least five minutes.

You may want to run Performance Monitor locally if you know there is a performance issue on the server, since Performance Monitor may not be able to capture data from a remote machine when it is running out of resources on the server. Running it remotely from a central machine is really best suited to situations when you want to monitor or baseline multiple servers.