myExperience @ Sky (detail)

AppDynamics Skills:
- Configured AppDynamics 3.9.2 for Node.js and End User Monitoring (EUM) Single Page Application (SPA)
- Conducted a POC on End User Monitoring and Provided valuable feedback to AppDynamics
- Conducted extensive POC on CPU Overhead of AppDynamics agents for Node.js
- Experienced issues while configuring application, resolved with AppDynamics support
- Used custom rules to provide unique names for Ajax requests


-- Issues Identified
- Identified an Issue with Cluster Node module which causes the master Node process to use only one of the Node worker process. This in turn limits the CPU usage to only one core.

Explore JMeter Results using Angular and d3

How to explore JMeter results using Angular & d3

Check out https://github.com/smarigowda/ngd3jmeter.

How to use?

1. Clone the repository git clone git@github.com:smarigowda/ngd3jmeter.git

2. Start a web server at the root directory of the cloned repository (ngd3jmeter). I use Python command - python -m SimpleHTTPServer 9988

3. Now open a web browser and type the URL http://localhost:9988/ngJMeter_tsplot.html you should see a time series plot.

4. You can change the data in the data directory and update the html file ngJMeter_tsplot.html to plot time series using your data

5. Hovering the mouse on the transaction point will display the elapsed time and transaction name

You can see the plots by accessing: http://smarigowda.github.io/ngd3jmeter/ngJMeter_tsplot.html

JMeter Load Test Strategy (draft)

> Use Cloud

> Use multiple JMeter Instances on Multiple Servers

> Distribute the load across Multiple Servers by scheduling JMeter tests to kick off on all Servers @ Same Time (linux cron job)

> Combine all CSVs and Prepare Report (scp, shell and awk)

> Use GIT to Version Control and Keep in SYNC JMeter Scripts and Data on All Servers

> Use Cloud

Use cloud for all the benefit it brings. I use AWS and Datapipe cloud.

> Use multiple JMeter instances and Multiple Linux Servers

For one of my scenario, I use one JMeter instance for every 30 concurrent threads, each JMeter instance having 512MB heap size (jmeter.bat:set HEAP=-Xms512m -Xmx512m), I spawn 30 JMeter instances on one JMeter server (CentOS 6.4 OS, Headless JMeter) which gives me 900 concurrent threads on one linux server. Server spec - CentOS 6.4, 16GB memory, 2.4GHz clock speed, quad core. This is specific to my scenario. You need to do some initial tests to find out how much load a server of this spec can support for your scenario. It is not a standard, it depends on your scenario. Use shell script to kick off 30 instances of JMeter (in a loop)

> Distribute the load across servers by scheduling JMeter tests to kick off on all Servers @ Same Time (cron job)

I use two JMeter servers (in Cloud) to simulate 900 * 2 = 1800 concurrent users

I initially tried JMeter’s distributed load feature it did not work for me. So I took a different approach. Using linux cron job I schedule tests (on multiple servers) to kick off at the same time. This way I can scale up the load by adding more CentOS linux servers in cloud.

> Combine all aggregate report CSVs and Prepare Report (scp, shell and awk)

Using scp download all the jmeter aggregate report csv files onto your local machine. Use awk to combine and filter all the csv files into a single aggregate csv file. This csv file can be opened in JMeter to get a single aggregate report. It takes a while to set this up, but once done, you can scale load by just adding more Linux servers and simply schedule tests whenever you need. Using cloud it just takes few minutes to spin up servers and setup jmeter.

> Use GIT

I keep all the jmeter scripts and data in a GIT repository. This allows me to keep control on versions of JMeter scripts, data and results and also helps to keep scripts and data in SYNC on all servers. I just clone the repository on a new server to get all the scripts and data ready to go.