Stop MongoDB in java

private static void stopMongoDB() throws IOException {
ProcessBuilder pb = new ProcessBuilder("taskkill", "/IM", "mongod.exe").inheritIO();
Process proc = pb.start();
try {
proc.waitFor();
} catch (InterruptedException e) {
e.printStackTrace();
}
}

calling the above method:

stopMongoDB();

Start Mongo DB in java

private static void startMongoDB() throws IOException {
ProcessBuilder pb = new ProcessBuilder("C:\Program Files\MongoDB\Server\3.6\bin", "mongod.exe").inheritIO();

Process proc = pb.start();
try {
proc.waitFor();
} catch (InterruptedException e) {
e.printStackTrace();
}
}


calling the Above  Method:
startMongoDB();

Start or Stop ActiveMQ in Java

Method:
private static void stopActiveMQ(String java, String mqPath) throws IOException {
File cwd = new File(mqPath);

ProcessBuilder pb = new ProcessBuilder(java, "-jar", "activemq.jar", "stop").inheritIO();
pb.directory(cwd);

Process proc = pb.start();
try {
proc.waitFor();
} catch (InterruptedException e) {
e.printStackTrace();
}
}

Calling the above Method:

stopActiveMQ("C:\Program Files\Java\jdk1.8.0_92\bin\java.exe", "E:\Softwares\apache-activemq-5.13.1\bin");

Data Modeling Guidelines for NoSQL JSON Document Databases

From mongo DB documentation .

https://www.mongodb.com/partners/hackolade 

Mongo DB Data Modeling explanation.

https://www.youtube.com/watch?v=IUxT7ZRHlZ4

Guide Lines.

Pair programming is an agile software development technique in which two programmers work together at one workstation.

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,^[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.

https://en.wikipedia.org/wiki/Pair_programming 

Pair programming is quite famous now-a-days.

It has several advantages like:

1.      Programs with fewer bugs.

2.      Post production maintenance cost is much less.

3.      Established practices are challenged resulting in emergence of new ideas.

4.      Programmers learn from each other.

5.      Programmers develop soft skills.

Although pair programming has gained considerable reputation, it has several pitfalls too.

Some of them are as follows:

1.      In pair programming you cannot sit back and self-evaluate your own code.

2.      One of the pair may stop being actively engaged.

3.      The driver needs to "program aloud". Silently programming reduces the benefit.

4.      It costs more man-hours to produce the same features. Balance must be maintained between quality of code and increased coding cost.

5.      A "watch the master" phenomenon may arise when an experienced and a novice programmer pair up. The novice member may become the observer with the experienced member completing most coding.

6.      When two experienced users pair up, a "developer's ego" phenomenon may arise, with each member trying to push his/her own ideas.

Design and implement RESTful web services with Rational Software Architect

REST (Representational State Transfer) is style of architecture that enables development of loosely coupled systems by using the HTTP protocol. Traditionally, the design of REST-based services (or RESTful web services) has been described in terms of the URIs, resources, HTTP methods supported by each resource, and their representations. Such descriptions are usually published as documentation to enable implementation of the service, as well as to enable the clients of the service to recognize and use the web service. Due to lack of any formal notation, such descriptions invariably exist in design documents as text and tables, which brings us to a few challenges in this approach:

1. How do you design your RESTful web service?
2. How do you implement this design?
3. How do you publish your RESTful services to make them available to users?
4. How do you evolve this design and implementation?

IBM® Rational® Software Architect Version 8.0.3 addresses these challenges within the paradigm of model-driven development (MDD), with the support for modeling and implementation of RESTful web services. The modeling support enables you to create UML models for your web service to describe your web service. The same UML model also serves as the source for generating documentation for those who use your web service. On the implementation side, you generate Java code to generate your web service, using the Java API for RESTful Web Services, or JAX-RS.

With this in mind, let's explore the REST modeling features of Rational Software Architect. By the end of this article, you will be able to design and implement a RESTful Bookmark service according to the UML model shown in Figure 1.

Figure 1. RESTful Bookmark web service model

Designing the web service

The design of the RESTful web service begins with a UML model. Rational Software Architect includes two template models to base your design upon (shown in Figure 2).

Figure 2. REST model templates

Choose the JAX-RS Service Model template if your final implementation of the RESTful service will be based upon JAX-RS. Or, if you are not concerned with the implementation yet or do not want to use JAX-RS, you can select the REST Service Model template. These model templates come preset with the various palettes and libraries that you will need to model the service.

After the model is created, you will normally see the main diagram of the model. On this diagram, you can see the REST palette on the left side, which you use to create REST elements, and a palette of the model elements to choose from on the right side.

Figure 3. Main diagram and REST palette

You use this palette to create various elements that form a RESTful web service.

Begin by creating an application.

1. Click the Application Class palette entry, and then click on an empty space in the diagram.
2. Name this class BookmarkApplication. This application class represents the root of the RESTful web service.
3. Next, you can add the RESTful resources that this application should expose.

Each resource is exposed at an URI and it can support any of the HTTP methods. For example, for Bookmark Web Service you can expose your resources in the ways that Table 1 shows.

Table 1. Resources and URIs

Resource	URI	HTTP methods supported
Users	/users	GET	getListofUsers
		POST	createUser
User	/users/{username}	GET	getUser
		DELETE	deleteUser
Bookmarks	/users/{username}/bookmarks	GET	getListofBookmarks
		POST	createBookmark
Bookmark	/users/{username}/bookmarks/{bookmarkId}	GET	getBookmark
		DELETE	deleteBookmark

From this table, you have the Users resource accessible through the /users URI at the root of your application.

4. To create resources, you can click on the Resource Class in the palette and then click on an empty space in the diagram, and name this class, Users.
5. REST URIs are modeled as paths. Hence, to model the /user URI, click the Path Dependency entry in the palette, and then click and drag from the BookmarkApplication class on the diagram to the Users class, and name this path /users.

Next you can add the REST methods supported by this resource.

For the Users resource, the software support HTTP GET and POST methods, so you can click the GET operation and then click on the Users class on the diagram, and name the operation getListofUsers.

Similarly, repeat these actions for the POST operation, and name it createUser.

Note:
From the REST perspective, these are GET and POST HTTP methods, but here you have given them more descriptive names.

Your diagram should now look something like Figure 4.

Figure 4. BookmarkApplication and Users diagram

6. You can now add the rest of the resources, paths, and operations.

Your final diagram will look something like Figure 5.

Figure 5. UML model

For the getUser GET operation on the User resource, notice that the URI is /users/{username}.Here, {username} is a parameter for this resource. To specify its use in the getUser operation, click the Param parameter in the palette, and then click the getUser operation on the main diagram. This will create a parameter for this operation.

Note:
After creating the parameter, it may not be visible on the diagram. This is because, by default, parameters are filtered out on diagrams. To make it visible, right-click on the User class in the diagram, and select Filter > Show Signature.

You can specify details of this parameter in the REST tab in the Properties view (Figure 6). For this parameter, select PathParam, because it is extracted from the path, and select username as the name. You can also specify that the parameter is a Header parameter or Query Parameter and so on, based upon your design. Additionally, you can specify a default value.

Figure 6. REST Parameter tab

For consistency, we recommend that you keep the UML name for this parameter the same as the REST name (or similar).

7. To do this, you can switch to the General tab and change the name to username.
8. Also in the General tab, you can specify the UML type of the parameter as String.

The difference in the REST type (PathParam) and UML type (String) is that the REST type is the type on the REST interface for the user of the REST service, whereas the UML type is the type of parameter that the implementation of the REST service will use.

For each REST method, you also need to specify the data format that it supports for input and output.

9. Select the getUser method, and switch to the REST tab in the Properties view.
10. Click inside of the Produces (or Consumes) list to specify the format.

There is a set of predefined values that you can choose from (see Figure 7), or you enter a type of your choice. For both Produces and Consumes, you can specify multiple types.

11. Select application/xml for the Produces section.

Figure 7. Properties that the REST method produces and uses

Further down in this tab you can specify the HTTP return codes that this method can return.

12. Click inside of the Return codes list to select a return code.
13. Select 200 OK as one return code and 404 Not Found as another.

The standard HTTP returns codes are available in the drop-down menu, or you can also type in your custom code. For each return code, you can specify an example of the content that can be returned and add a description in the Content and ‘Description text boxes, respectively.

Figure 8. REST method return code properties

Modeling RESTful interactions in sequence diagrams

You can model the typical interactions with the clients of your RESTful web service by using the sequence diagrams. The calls between the client and your service are essentially HTTP calls; therefore, an HTTP interaction element is provided within the HTTPReference library (see Figure 9).

Figure 9. HTTP interaction elements

The HTTPReference is already imported into your models if you used the REST or JAX-RS template model to create the model.

The HTTP Interaction element is used to represent both the client and the RESTful web service.

1. To use this on a sequence diagram, click and drag the HTTP Interaction element from the Project Explorer onto a sequence diagram, and give it an appropriate name, for example Client for client,Bookmark Service for the web service.
2. You can now draw messages between the client and the web service.
3. As you draw each message, you can select a type of operation from the list of HTTP Requests and Responses for that message from the drop-down menu (Figure 10). Typically, for messages from the client to the web service, you would choose a GET, POST, DELETE request, for example.

Figure 10. HTTP request on a sequence diagram

4. And for the return, select a return code, such as 200 OK.

Figure 11. HTTP response on a sequence diagram

5. You can also detail each request or response in terms of the URI, headers, and content by using the HTTP Properties tab for a message (Figure 12).

Figure 12. HTTP method details

The sequence diagram support is very useful for the clients of your web service to understand the workflow supported.

6. For the implementation side, you can further details the sequence diagram with calls to actual resource classes by simply dragging your resource classes onto the sequence diagrams and drawing messages to the diagram.

Figure 13. Sequence diagram for implementation

Generating documentation using BIRT reports

Business Intelligence and Reporting Tools (BIRT) reports are an easy way for you to share or publish your RESTful web service documentation. Rational Software Architect includes a REST report template to use with your REST Models. You can also edit and enhance the report according to your documentation needs.

1. To create a REST report, select File > New > Other > REST Modeling Reports > REST Report.

Figure 14. REST report

Implementing the web service using JAX-RS

When the model is ready, you can use the UML-to-Java transformation with the JAX-RS extension to generate the implementation for the service. However, before doing that, you need to add a few of the JAX-RS specific details to your model.

The first detail is sub-resource locator operations. In the REST model, you drew the Path dependency to provide navigation from one resource to another.

1. In the JAX-RS implementation, you need to create a sub-resource locator operation in the source resource. You can create a SubResourceLocator method from the palette.

Figure 15. JAX-RS palette

2. For the locator operation to be completely defined, you need to set its return type as the target resource and also set its locator stereotype property (SubResourceLocator) to the path value (<Path/bookmarks> in this example), as Figure 16 shows.

Figure 16. Sub-Resource Locator properties

3. Also, you need to add JAX-RS specific types to your operations.

For example, you might want to use the javax.ws.rs.core.Response object as a return type. Such types are available in the JAX-RS reference library (see Figure 17).

Figure 17. JAX-RS reference library

4. Now you can create a UML-to-Java transformation configuration to generate the code for the service. The source of the configuration should be the model that you created, and the target should be a dynamic web project, which is enabled with JAX-RS libraries.
5. You will also need to need to enable the JAX-RS UML-to-Java5 extension (Figure 18) on the extensions tab of the transformation configuration.

Figure 18. JAX-RS UML-to-Java5 transformation extension

This extension takes care of generating the JAX-RS annotations on the Java classes and the required web.xml file updates for the service.

6. Running this transformation will generate the required Java classes for your implementation, and there you can add the required implementation logic to your classes.

You can now package and deploy this application on an IBM® WebSphere® Application Server with Feature Pack for Web 2.0 and Mobile, which supports JAX-RS.

7. If you have the WebSphere Application Server Test Environment installed with Rational Software Architect, you can right-click on your dynamic web project and select Debug As > Debug on Server, and select the test server.

After that, you can test and debug your RESTful web service within the Rational Software Architect environment.

Note:
You can use any JAX-RS implementation to deploy your implementations (for example Apache Wink, for example). It is not necessary to use WebSphere Application Server.

The UML-to-Java transformation with the JAX-RS extension provides complete support for round-trip engineering. So you can model and generate code, and then later refine the model and update the code, or even update the code and use UML-to-Java transformation in Reconcile mode to update the model from the code.

If you already have an existing dynamic web project based upon JAX-RS, you use the Java-to-UML transformation with the JAX-RS extension to generate a UML model from your project. This can serve as good starting point for you to understand your existing JAX-RS implementations and refine them further.

Source : https://www.ibm.com/developerworks/rational/library/design-implement-restful-web-services/

How to Get and Run VisualVM for Profiling

How to Get and Run VisualVM

The good news here, you actually don’t need to do anything, it is already available in the JDK bin directory. It’s available after JDK 1.6 update 7. Once you are in the bin directory of JDK, you will find jVisualVM.exe; just click on it, and the application starts up.

Step 1: Go the Java Bin directory and click on the jvisualvm.exe

Step 2: On clicking the above .exe we will get the following screen.

Step 3: When we run the Tomcat, then automatically the pid will be detected by VisualVM and will be showing in the following manner.

The on top-left you can see application tab, and under this, you can see different options like Local, Remote and Snapshots. To set a remote application profiling, you must connect to the remote server and add that application:

While setting up the remote application, you can give it name as well, “Display name:.”

Benefits

There are many important features that VisualVM supports, such as:

1. Visual interface for local and remote java applications running on JVM.
2. Monitoring of application’s memory usage and application’s runtime behavior.
3. Monitoring of application threads.
4. Analyzing the memory allocations to different applications.
5. Thread dumps – very handy in case of deadlocks and race conditions.
6. Heap dumps – very handy in analyzing the heap memory allocation.

So if you see the above list, you can actually monitor your applications — both local and remote — which is quite handy in case of a run time exception, like outOfMemoryException, deadlocks, race conditions, etc., as you get to visually see which objects are causing an outOfMemoryException, for example, or the objects/resources causing thread deadlock.

Web applications Performance Testing Metrics

Introduction

Few years back the use of World Wide Web (WWW) was limited to services industry but today this is web era where everything is over the web. Now organizations are not only providing online services to their clients but also using this platform to completely run their businesses. This excess of use and importance of online services also greatly demand for their hassle free delivery. These days’ users are very demanding and user abandonment starts as they received response time greater than 3 seconds. Slow performing applications have direct impact on business performance and according to a study $45 billion business loss occur yearly due to poorly performing web applications.

Performance testing is conducted to make sure the application under test (AUT) will meet user expectations in production environment. Based on the results of the performance testing activity, required actions are taken to fill the gap between the actual and expected results. As effective measurement is the key for the success of any process, similarly performance testing activity required results can never be achieved without having clearly defined success criteria. Different performance testing metrics are used to measure the output of the performance activity. These performance metrics provides the quantitative method to evaluate the test results. Information obtain from these metrics assist organizations to improve their productivity, drop error rate and improve product quality and services level to achieve their desired business goals.        

There are dozens of performance counters which are generated during the performance test and it’s almost impossible to thoroughly evaluate each of them. Being a good performance engineer, one must have strong understanding of performance problematic areas of the AUT and right set of performance counters of each of these areas. In this discussion, I will highlight different aspects of performance metrics, potential performance problematic areas of web applications (Clint side, Web Server, Application Server, Database Server and Network Configurations) and performance counters of each of these areas in details which need to be monitored during performance testing.     

What is Metric?

Metric is a standard unit of measurement which calculates the results. Software Metrics are used for the evaluation of software product and its services.

Performance testing metrics are used to evaluate the application performance parameters and to identify which areas of the application are creating performance bottlenecks.  

Importance of Metrics

Quantitative results always provide the best outcome of an activity and metrics help in getting these quantitative results. Following points also highlight the importance of performance testing metrics,

• Metrics are used to improve the product quality to achieve better customer satisfaction
• Metrics provide easy and clear output of the activity and identify areas which need more attention
• Metrics help in comparing the results of different test to find out the impact of any change in application
• Metrics are monitors which provide the exact cause of problem
• Metrics establish baseline for all tests
• Metrics track project progress

Metric Characteristics

There are dozens of metrics generated in performance test but it’s not possible to evaluate all of them. Specific performance metrics are selected based on following characteristics,

• Metrics whose complete and accurate data can be collected should be evaluated
• Metrics which are important in the context of the application should be evaluated
• Metrics which are easy to calculate should be evaluated

Performance Testing Metrics selection

It’s normally depends upon the AUT performance goals to decide which software metrics should be evaluated. But there are few generic metrics which are normally considered in every performance test as listed below.

Performance Test Requirement Gathering Metrics

The scope of test and its activities always depends upon the requirements. Having crystal clear requirements before starting the performance testing activity is a fundamental step. A test with vague requirements can never achieve its desired results. So in first phase being a performance engineer, one need to identify the set of metrics required for gathering complete list of performance requirements. Different stakeholders can be contacted to collect performance requirements but viewing the server log is also helpful activity. Following server side metrics are considered for a live application to establish performance goals,

• Total Page Views per Week
• Total Hits per Week
• Total User Sessions per Week
• Average Page Size
• Average Hit Size
• Page Request Distribution
• User Abandonment

Total Page Views per Week

Page view is the request on server for that specific page with all its embedded objects. This metric provide the information about the weekly traffic on AUT. Choosing the page views metric over page hits or byte transferred is preferred because it’s commonly used as an indicator for website traffic. Moreover, choosing the weekly limit also provides more realistic application traffic analysis over choosing the specific hours and day traffic.

Total Hits per Week

A hit is any resource (web page, image, files etc.) request received by the web server from the client. Several hits are made on server when client request for a web page. Web pages normally made of number of images and files and number of hits to web server for a specific web page will be equal to the number of resources it contains.

Total User Sessions per Week

A user session is a unique user visit on the website. This user uniqueness is maintained with many different approaches like with username and its password, browser cookies and the user machine IP address. Tracking user session is very handy in load testing because it’s not only provide the information of number of users accessing the application but also provide the user navigation trends on the application which is very important to simulate real user load during testing.   

Average Hit Size

This is the average amount of data user received from the web server against a particular hit. Average hit size is measured in Kbytes.

Page Request Distribution

Page request distribution metric represent the user request distribution in percentage across all the website pages. This metric provides useful information on user trends and help out in deciding the user distribution on performance schedule. 

User Abandonment

This metric provides the information on amount of time an average user waits for a page load before exiting from the application in dissatisfied manner. This value helps in deciding about the user acceptable response time limit.

Client-Side Requirement Gathering Metrics

End users who interact and use the application to fulfill their specific requirements are called clients. The usage patterns and the application behavior to all these clients can vary greatly depending upon different variables which are called client-side variables and simulating all user requirements is necessary for designing effective performance test. Following client side metrics should be considered while designing a performance test,

• Interaction Speed
• Latency Tolerance
• Familiarity
• Connection speed
• Location

Interaction Speed

Interaction speed represents the user interaction speed with the applications. This variable represents the how fast a user perform business actions on a web page and navigates between different web pages.

Latency Tolerance

This variable provide the information of how much a user waits for page response before taking next action which could be application abandonment, page reload etc. Today on average a user waits for 3 seconds for a webpage to load before taking any action.

Familiarity

This variable represents how much user is familiar with the application. Frequent users are always able to complete the required task with much ease in much less time as compared to new visitors.

There are few client-system variables as well which needs to be considered before starting the load testing,

Connection speed

It’s important to know what percentage of users is using which internet connection. Application response time will be much lower on fast internet connection as compared to lower connection. Moreover for realistic performance test, this internet connection bandwidth should be considered for virtual users as well.

User Geographical Location

User geographical location also greatly affects the user experience on the application. Application response time will be less for lesser number of hops between the client and the server.

We have discussed the requirement gathering metrics and now need to discuss the performance metrics evaluated during the performance test. Performance testing metrics can be divided into following broad categories,

• Vuser Monitoring
• Transaction Monitoring
• Web Resource Metrics
• System Resource Monitoring
• Web Server Performance Metrics
• Application Server Performance Metrics
• Database Server
• Network Monitors
• Client Side Metrics

Vuser Monitoring

It’s very important to know the status of every user on every executed transaction to analyze the impact of increasing workload on the system. There are various graphs available in every performance testing tool for monitoring the Vusers activities and some of the most important are as following,

Running Vusers Graph

Running Vusers metric provides the complete information of how many users are running, how many are waiting for their turn and how have executed at any particular time of the test. It provides the information of number of users currently accessing the application.

Vusers with Errors Graph

One of the most important factors while analyzing the executed performance test results is to know how many users were unable to complete their actions and which errors they faced. Knowing this information not only provides the application performance insights but also help in identifying the problem root cause.

Transaction Monitoring

Transactions are business processes which are executed for certain user to test the application performance. It’s vital to know the status of each executed transaction and its response time. Following are some of the important metrics which should be carefully monitored during the performance test,

Average Transaction Response Time 

There is no doubt that response time is the most user concerned performance parameter. An application or transaction with slow response time will never be accepted to users. So each executed transaction response time is monitored during every second of the scenario run to evaluate the running users’ impact on performance. These days average transaction response should not be more 3 seconds otherwise user abandonment started.

Passed/Failed Transactions

Sometimes (especially for business critical applications) it’s more important to complete the certain business transaction rather than their slow response time. So knowing the information of how many transactions passed and failed during the performance test is also extremely important.

Web Resource Metrics

Web resource metrics provide the web server parameters information captured during the performance test. Following are few important web server metrics which should be monitored during the performance test,

Hits per Second

Hits per second graph provide the information of number of HTTP requests sent to the web server during specific time period of the performance test. This is one of the most important metric which shows how the application behaved on increasing the user load. Hits per second increased by increasing the user load unless the application is able to handle that specific user load.

Throughput

Throughput graph provide the information on server response during specific time period of the performance test. This is also extremely important metric as it provides the information of web server response against the user requests. Throughput value is also directly proportional to user load unless web server is successfully able to handle that specific user load under those conditions.

HTTP Responses per Seconds

HTTP responses graph provide the information of all the HTTP status codes generated per second during the performance test execution. These values provide useful information on web server state during every second of the performance test. Following is the summery of response codes,

1XX: Informational (Client request is received)

2XX: Success (Client request is received, accepted and processed successfully)

3XX: Redirection (Client needs to take extra actions to complete the request)

4XX: Client Error (Error in client request)

5XX: Server Error (Server failed to complete the request)

Errors per Second

A poorly performing application not only takes more time in completing its business transaction but also generate different types of errors as well. These errors stopped users to complete their transactions. All errors don’t have the same impact on the AUT. The seriousness of the error can be analyzed from its HTTP response code as mentioned above.

Pages Downloaded per Second

This graph displays the information of web pages downloaded in every second of the test from the web server. This metric provides the useful information on amount of load generated by virtual users on the web server in terms of web pages.

Connections per Second

Information on number of new TCP/IP connections opened and shut down during each second of the performance test is provided with connections per second graph. Connections opened/shut down should be smaller than the hits per second as TCP/IP connections are very expensive. To the best interests of the system, several HTTP request should use a same TCP/IP connection.

System Resource Monitoring

Monitoring all the machines (Servers and load injectors) and their operating system resources which are being used in performance testing is also provides useful insights in analysis. Modern performance testing tools provide the facility to monitor resources on all machines being used during the test to pin point the performance bottleneck root cause. Following metrics are usually considered across all systems while a performance scenario is running,

CPU Usage

This metric provides information on machine CPU utilization. For effective application performance CPU utilization should not be more than 70%.  

Memory Usage

Memory usage provides the information on amount of free disk space, virtual memory pages moved between main memory and disk storage and percent memory used during the scenario execution.

Disk Space Usage

This metric provides the information on percent disk space is used.

Service Monitors

It provides the information on running processes on the machine and the amount of system resources they are using. The problematic processes which use more resources can be identified and fixed quickly from these monitors.          

Web Server Performance Metrics

Web server metrics provides the information of resources usage on web server during the performance test. These metrics provides the useful information on web server performance and its bottlenecks. There is long list of metrics which are generated during the performance depending upon the type of web server. Apache HTTP, Microsoft Internet Information Services (Microsoft IIS), Lighttpd, Sun Java System and Jigsaw server are famous web servers. As I mentioned above, list of performance metrics monitored during performance test varies with the type of web server, following is the list of performance counters to need to be monitored for Microsoft IIS web server during performance testing.

• Bytes Sent per Second
• Bytes Received per Second
• Get Requests per Second
• Post Requests per Second
• Maximum Connections
• Not Found (404) Error per Second
• Private Bytes
• Percent of Processor Time
• System Processor Queue Length
• Percent Disk Time
• Queue Length
• Cache Hit Percent
• Request Wait Time
• Request Queued
• Transactions per Second

Application Server Performance Metrics

Most of the application computational activities are performed on its application server. We can say application server is the back bone of the application especially in case of highly complex business applications. Web Sphere, JBoss, Apache Tomcat, Web Logic, Microsoft .Net, and Oracle Application server are some of the famous applications servers being used these days.  

Every type of application server has its performance counters based on its model. Following I am listening some of the Web Sphere application performance counters which needs to be monitored during the performance test,

• Memory Free
• Total Memory
• Memory Use
• Bean Destroys
• Active Threads
• Total Threads
• Percent Time Maxed
• Connection Wait Time
• Connection Time
• Connection Percent Used
• Active Transactions
• Transactions Suspended
• Rolled Back
• Timeouts
• Servlet Errors
• Sessions Invalidated

Data Base Server

All the application data is stored in database and the system on which database is installed is called data base server. As the database server contain all the critical information of the application, its fast and error free working is extremely important. Oracle, DB2, Microsoft SQL Server and Informix are famous database servers. Some of the common metrics monitored for all database servers are following,

• Database Transaction Summary: Database transaction monitor provide the information of volume of data sent and received by the database server. It provides the detail in bytes of requests sent and received during the performance test.
• Database Connection Summary: This metric provides the information of total number of open and close connections on database server during the test. Excess of database connections can badly affect the database server performance.
• Database Thread Summary: Thread metric provides the information of number of new threads created, connected and used.
• Database Query Summary: Read, write and delete data are main database functions and their detail is very important to check the database server performance during the performance test. Database Query metric provides the information of total number of queries read, wrote and deleted by the database server.

Some of the most important performance counters of Microsoft SQL Server are following,

• Transactions per Second
• Log Cache Hit Ratio
• Log Cache Reads per Second
• Log Bytes Flushed per Second
• Log Flush Wait Time
• Log Flush Waits per Second
• Log Flushes per Second
• Percent Log Used

Network Configurations Metrics

Network configurations play a vital role in application performance. An application can never perform well if its network is poorly designed. Each application network consists of multiple segments and it’s very important to properly monitor each and every network segment delay time during the performance test. All Modern tools are equipped with the facility to configure the network monitors in performance test environment to see the impact of network configurations on application performance.

Some of the important network metrics within a network segment which needs to be monitored during the performance test are following,

• Bytes per Second Sent to Network Interface Card
• Bytes per Second Received by NIC
• TCP Segments Sent per Second
• TCP Segments Received per Second
• TCP Segments per Second
• TCP Segments Retransmitted per Second
• TCP Connections Failures
• TCP Connections Reset
• TCP Connections Established

Client Side Performance Metrics

According to a Yahoo study, 80-90% of the web page load time is spent on front-end and its application performance can be improved up to 40% by cutting half of the front end load time. Performance engineers are keenly focusing the front end usage of resources as users are demanding better applications performance. Good performance testing tools provide the details of time consumed on various web pages resources like images, JavaScript files, CSS, html, DNS connection, TCP connection, SSL handshake, HTTP Request, HTTP Response status and response size. Some of the client side metrics need to be monitored during performance testing are,

• Images Load Time
• JavaScript Files Load Time
• CSS Files Load Time
• HTML Resources Load Time
• DNS Lookup Time
• TCP Connection Time
• SSL Handshake Time
• Time to First Byte
• Content Download Time
• Content Caching Policy
• Availability Content Delivery Network (CDN)
• Resources Rendering Time
• Number of HTTP Requests
• HTTP Response Status
• HTTP Response Size

Conclusion

Quantitative results always provide the clear picture of a situation and keep track of changes. Performance testing metrics provides quantitative results which helps performance engineers in test analysis. Specific Vuser, Transaction, Web Server, Application Server, Database Server, Network Configurations and Client Side metrics are need to be monitored during the performance test to determine the application current performance and to find out its problematic areas and their root causes. 

Source : http://www.agileload.com/agileload/blog/2013/02/18/web-applications-performance-testing-metrics