Home     RSSRSS

Archives: Performance Center

Concurrency, Thread Safety and Local Variables

August 12, 2016 by kiranbadi1991 | Comments Off on Concurrency, Thread Safety and Local Variables | Filed in Development, Performance Center, Performance Engineering, Performance Test Tools

One of the most of the common reason for concurrency issues I often see in web application is due to concurrent access of data stored in variables. Generally in servlets , data in variables are often stored as Local variables, Instance Variables, Class Variables , request attributes, session attributes and context attributes.

Below example simplest I can think of for storing data as local variable and accessing it in a thread safe manner

public class MyServlet extends httpServlet {

  // mylocalage is localvariable here for this servlet.

    public void printAge(){
              int mylocalage = 0;
      mylocalageage = mylocalage - 10;
      System.out.println("My age 10 years earlier was: " + mylocalage);
      

    }
}

Its considered that by design that data stored in local variable is thread safe.

Every thread accessing the above servlet will have their own values and they will not interface with each other.

image

Local variables are stored in stack in Java. So data stored in these variables are thread safe.

Tags: , ,

Transaction Response time–First Indicator of Application Performance

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

What do you mean by Transaction ?

What do you mean by Transaction Response time ?

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

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

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

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

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

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

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

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

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

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

Tags: , ,

Monitoring Java based Servers with JMX

January 5, 2014 by kiranbadi1991 | 1 Comment | Filed in Development, Environment, Performance Center, Performance Engineering, Web Server

Many times I have seen people struggling to do monitoring set up on the Java based servers like Web logic , Web sphere or even commercial servers like Tibco etc. Any server which supports Java based application can be monitored with JMX Solutions. Even the commercial tools like Sitescope, Silk Performer Monitors use the Custom JMX Client classes behind the scenes to monitor the java based servers.

JMX provides the powerful API to monitor and manage any Java based application servers or infrastructure. Below are some  benefits which I have seen we get by using the JMX API,

  1. Using the JMX we can monitor the health of all servers in the environment. Even if we have non Java based servers , we can always  write the custom wrapper classes which can pull the performance stats from those servers. However this approach consumes some time, but is doable if we have skilled java resources. However if we have Java based infrastructure than probably other than enabling JMX , there is hardly any code is required.
  2. Configuring Resources on the server is also possible with JMX API. With JMX API we can monitor and configure the application and its services either fully or in part by exposing it to the JMX API.
  3. JMX also helps in debugging. Debugging can be enabled at runtime in case if required.
  4. JMX can also send out the alert notification, emails for critical events.However a listener needs to be Configured to send out the actual data.

Setting the JMX Based monitoring on the java based server involves the enabling the JMX Port in the start up option of the server. Normally it’s the flag which needs to be set up in java options of the server.

In this post I will show you as how to do set up in Apache Tomcat 7x server. I have installed the Apache Tomcat on my local machine as windows service.Once you have installed Tomcat as service, navigate to the bin directory of the server and right click tomcat7w.exe file. Please make sure that you run this with administrator rights.

image

In apache Tomcat 7 Properties windows, click on Java tab, you need to enter below options for local monitoring solutions.Please note that with below options we have turned off SSL and authentication is also switched off which means that you don’t need user id and password to connect to the server.

-Dcom.sun.management.jmxremote=true 
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=false

For remote monitoring of the server we need to enable remote port for jmx. Below options I have shown as how to set JMX Monitoring with user credentials, however if you don’t need user credentials, then probably, you can use options jmxremote.authenthicate as false.

-Dcom.sun.management.jmxremote.port=(your port number)
-Dcom.sun.management.jmxremote.ssl=false 
-Dcom.sun.management.jmxremote.authenticate=true
-Dcom.sun.management.jmxremote.password.file= path to password file

Below screenshot shows you the setting I have given in my tomcat server. Since JMX is based on JMX Specification, set up is pretty should be similar in other java based servers. However in those servers, we might set the java options in class path options while starting the servers.

image

Once the JMX options is enabled, we can use any JMX Client to connect to the server and gather the performance metrics. However please do note that application and server need to expose its functionality via Mbeans. Below screenshots shows the connection with JConsole,

image

Enabling the JMX Options is the first step you need to do if ever you want to monitor any java based servers with JMX.

Lot of people also say that enabling the JMX is cumbersome process, but my experience was bit different and after enabling it did not break any thing on my environment set up.

Technorati Tags: ,,

Tags: , ,