Saturday, May 16, 2015

Disk I/O in Amazon RDS and EC2 instances


Disk I/O in Amazon RDS/EC2 instances
 
Amazon RDS/EC2 uses EBS volume for database and log storage. Depending on the size of storage requested , Amazon RDS automatically stripes across multiple EBS volumes to enhance IOPS performance.

Amazon EBS provides 3 volume types :

1. General Purpose (SSD) volumes
2. Provisioned IOPS (SSD) Volumes
3. Magnetic Volumes

Before we further discuss characteristics of each of these EBS volume, let us first take a look what IOPS are and how measurement take places for these.

What are IOPS:

IOPS are input and output operations per second. Amazon EBS measures each IO operation per second ( that is 256 kb or smaller) as one IOPS. I/O operations larger than 256KB are counted in 256KB units. For example 1024 KB I/O operation will be counted as 4 IOPS.

General Purpose (SSD) volumes:

General purpose (SSD) volumes offers cost effective storage that is ideal for a broad range of workloads. These volume can offer single digit millisecond latency , the ability to burst to 3000 IOPS for extended period of time. These volume can range from 1 GB to 16 TB.

General purpose (SSD) volume provide baseline performance of 3 IOPS/ GB and maximum of 10000 IOPS  (3334 GB). Throughput of these volumes range in between of 128 MB/s to 160 MB/s.

Performance of general purpose (SSD) volume is governed by volume size.  Higher the size , higher accumulation of I/O credits where I/O credits represent available bandwidth that General Purpose (SSD) volume can use to burst large I/O when more than baseline performance is required.

Provisioned IOPS (SSD)  Volumes:

Provisioned IOPS (SSD) volumes are designed to meet the need of I/O intensive workloads , mainly database workloads that are very much sensitive to storage performance.  Here while configuring (creating volume) provisioned IOPS (SSD) volume, we have to specify desired IOPS rate.  These volume can range from 4 GB to 16 TB with a maximum throughput 320 MB/s. We can achieve maximum of 20000 IOPS with these volumes.

Magnetic Volume:

Magnetic volumes provide the lowest cost per gigabyte of all EBS volume types. Magnetic volumes are backed by magnetic drives and are ideal for workloads performing sequential reads, workloads where data is accessed infrequently, and scenarios where the lowest storage cost is important. These volumes deliver approximately 100 IOPS on average and they can range in size from 1 GB to 1 TB. 


 

Wednesday, May 13, 2015

APM - Real User Monitoring Vs Synthetic Monitoring


As part of setting up application performance monitoring framework , this is very critical to measure end user experience. End user experience monitoring sits on the top of APM framework. Further business judge their web application performance in terms of responsiveness of application. There are two approach by which we can monitor end user experience :

1. Real User Monitoring ( RUM)
2. Synthetic Monitoring

Real User Monitoring ( RUM):

While server side performance can be measured by looking HTTP requests in data center, full page load experience which includes downloading of static contents, rendering page, executing java script - can not be seen from server monitoring aspects. Real User Monitoring is the practice of using java script agent embedded in web page to gather performance data about end user's browsing experience.

Synthetic Monitoring:

Synthetic performance monitoring involves having external agents which run scripted transaction against web application. These scripts are meant to follow steps which is expected from typical user behavior. This might be searching product , log in activity, hotel booking etc.  Synthetic monitoring don't track real user's session.

We have to careful while setting up monitoring , which one best suites to our needs. While Synthetic monitoring provides details about reliability, availability whereas RUM provides real user browing experience.

Happy Monitoring !!!!!



Tuesday, May 12, 2015

String Deduplication - New Java 8 update 20 feature


Duplicate Strings in JVM heap ..Worried ??


During JVM heap dump parsing, it is quite common to visualize that Strings are consuming lots of heap space. Especially char[] are always ( most of the cases) present as biggest object in histogram.

If we perform a deeper analysis on String objects it is quite common to encounter thousands of duplicate String instances. Controlling these duplicate Strings may provide improvement in overall JVM memory footprints.

With Java 8 update 20 we now have a new features called String Deduplication which require G1 garbage collector in place and this feature is turned off by default.

Here G1 GC identifies Strings which are duplicated more than once and correct them to point to same internal char[], to avoid multiple copies of the same string.

Parameter :  -XX:+UseStringDeduplication

How to capture Connection Time in Jmeter 2.13


Jmeter 2.13 has introduced a new key performance indicator that is connection time.  Why is this important  ? It takes time to connect to a server before making a HTTP request and this can have impact on response time , specially for HTTPS traffic.

Starting from 2.13 version , new metric ConnectTime has been added. It represent the time to establish connection. By default it is not saved to CSV or XML. In order to save it we need to add following line in user.properties :

jmeter.save.saveservice.connect_time=true