"PetGym" is on my github now -- Automated your Jmeter tests

Jmeter PluginCMD provide a capability for running jmeter tests automatically with many cool reports generated: http://code.google.com/p/jmeter-plugins/wiki/JMeterPluginsCMD

I am writing a ruby program to meet my basic requirement during my performance tests.
Please check it out if you want to give it a try: https://github.com/joychester/PetGym

FastMole is on my GitHub now!

FastMole which is one of my project to do Continuous Page performance tests is on my github now: https://github.com/joychester/FastMole

My New Life, My Baby Girl!!

My lovely baby girl comes into my life for 2 weeks!! My life is going to be changed from now on :-)

Generate Load by adding reasonable think time

I used to generate load by launching small number of VUs without any think time during performance testing. The pros is You can trigger a very high load/Throughput even you are not creating many concurrent threads, but the cons is you can not generate consistent/stable load to make comparison once you make some tuning or changes. Recently, I am discussing with my teammate ZhouZhou, and figure out how we generate a consistent load by adding reasonable think time(Little Law helps the calculation here) between each request, here is the diagram we made to show how much load/Throughput we can generate/get:

Monitoring your load generator client, when the server CPU% is under utilized

Recently, I am using one Virtual Box(VMware/2 Cores / 8GB) to conduct performance/load testing. With more and more load Jmeter generate, It seems the server's CPU% is not able to go up...
However, I noticed the my vitual-box client's CPU% has reached to 90%+. After changing to a physical and more powerful machine, everything is fine, server side CPU% can go up with increasing payload. I am not often to monitoring load generator client during my testing previously, and they are usually works fine as its physical machine.
You have to monitor your load generator machine as well when you find the server CPU% is under utilized(stay the same with even higher user load) and Server response time keep increasing, especially if you are using a Virtual Box to do performance testing, then please be caution!!

Deal with Modal Dialog in my WebDriver test

If  you do not have an idea how to deal with the Modal Dialog in WebDriver Tests, here is my solution to it
For example the modal dialog pop-up after clicking "Logout" link, so the code like this:

 driver.findElement(By.linkText("Logout")).click();  
 driver.switchTo().activeElement().sendKeys(Keys.ENTER);  
 driver.switchTo().alert().accept();  

"Mouse" hover to your WebElement as a bonus in case you are looking for:

 //simulate the mouse hover  
 Actions builder = new Actions(ldriver);  
 Action action = builder.moveToElement(sportslink).build();  
 action.perform();  

Hope it helps!

Performance doc written by me and the team

First of all, Thanks to Neil Feng, if you are not pushing me hard, I won't write something down :) Thank you and the team!You are awesome guys!!

I think it is a good things can be shared with anyone who is interested in performance engineering stuff, so in case you want to take peek at it...:

https://docs.google.com/open?id=0B_hz_q1i5QXJTXZqd0FVblAzNms 

Hope it helps! Any comments or suggestions are welcomed!

--Cheng Chi

Add time stamp to your GC log file name

To avoid overwriting your gc log once the service restart expected, you had better to add a time stamp to your gc log file, simply as this:

 rem Tested FOR WIN7 OS:  
 rem set time format:  
 set hour=%time:~0,2%  
 if "%hour:~0,1%" == " " set hour=0%hour:~1,1%  
 set min=%time:~3,2%  
 if "%min:~0,1%" == " " set min=0%min:~1,1%  
 set secs=%time:~6,2%  
 if "%secs:~0,1%" == " " set secs=0%secs:~1,1%  
 rem set date format:  
 set year=%date:~-8,4%  
 set month=%date:~0,2%  
 if "%month:~0,1%" == " " set month=0%month:~1,1%  
 set day=%date:~3,2%  
 if "%day:~0,1%" == " " set day=0%day:~1,1%  
 set datetime=%year%%month%%day%_%hour%%min%%secs%  
 set GCLOG=-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc-%datetime%.log  

The output like this: gc-20120507_172101.log
Notice: "-XX:+PrintGCDateStamps" option is only available for JDK6u4+, otherwise, you need add "-XX:+PrintGCTimeStamps" instead. Never leave any space at the end of line in your batch script, it will trigger stupid result...

The Third Party Performance Problems

We live by the third parties, but do not expect them perfect...

We used a lot of third party stacks on each project, and they are almost used in the similar way most of time, so creating this lists to avoid such kind of traps in future, just give you some examples we met before:

1> HashMap.put() is not thread safe, however Axis manipulate it in parallel which leads to an infinite loop (it will cause 100% CPU usage unless restart the service)
Bug for tracking: https://issues.apache.org/jira/browse/AXIS-2792
Update:
a good post for explaining this problem in detail: http://coolshell.cn/articles/9606.html
here is an English version: http://mailinator.blogspot.com/2009/06/beautiful-race-condition.html
and how Doug Lea said about this in Sun's bug tracking system a few years ago: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6423457

2> Jetty service no responding by Deadlock (The Jetty can not respond to any coming request ,you have to restart the service)
Bug for tracking: http://jira.codehaus.org/browse/JETTY-1264

3> A JDK regression results in an indefinite wait for a connection which is created by Jtds or other JDBC drivers, so do not upgrade JDK version 1.6.0_27+ (said to be fixed in _30)
Bug for tracking: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7105007

4> Jtds-1.2.2 has introduced a few performance issues , including memory leak and infinite loop issues, you may consider to upgrade it after checking the history release notes:
http://sourceforge.net/news/?group_id=33291

Feel free to add more findings ;)

Algorithem Matters to Performance

If we want to find all Prime number within a positive range, how would you figure it out? I want to share with you with a simple code on how algorithm matters to performance: I am using Ruby to demo the difference between 2 ways to organize your code and how they impact the performance: Without any optimization:

 require 'ruby-prof'  
 def findprimenumber(uppernumber)   
  count =0;   
  for i in 3..uppernumber   
   primebool = true;   
   for j in 2...i   
    if (i%j!=0)   
    next;   
    else   
    primebool = false;   
    break;   
    end   
   end   
   if(primebool)   
   count= count+1   
   end   
  end   
  puts("total prime count:#{count}");   
  puts RubyProf.measure_process_time   
  end   

With optimization:

 require 'ruby-prof'   
 def findprimenumberopt(uppernumber)   
  count =0;   
  for i in 3..uppernumber   
   primebool = true;   
   if i%2==0   
   primebool = false;   
   next;   
   else   
   *for j in 3..Math.sqrt(i).floor+1 *  
    if (i%j!=0)   
    next;   
    else   
    primebool = false;   
    break;   
    end   
    *j=j+2;*  
   end   
   end   
   if(primebool)   
   count= count+1   
   end   
  end   
  puts("total prime count:#{count}");   
  puts RubyProf.measure_process_time   
  end   

Given the uppernumber to 100000 The performance result without optimization code :47s The performance result with optimization code :0.9s Also you may try more optimization way such as divide and conquer by parallel computing...