Dear Wiki user, You have subscribed to a wiki page or wiki category on "Jakarta-jmeter Wiki" for change notification.
The following page has been changed by robertpnz: http://wiki.apache.org/jakarta-jmeter/LogAnalysis The comment on the change is: another big refactor of the stuff wot i rote ------------------------------------------------------------------------------ attachment:scripts_jmeter.zip - = Testing a High Volume Webservice: Simple Data Writer, Bash scripts & Excel Graphs = - JMeter was used to test a new high-availability webservice/integration layer, exposed to a few internal clients (see also [:../UserManual/BuildWSTest:BuildWSTest]). Several instances of JMeter represented the different clients and varying load profiles. The main problems were: - *The default JMeter XML output is too verbose, and the files grew too enormous, so the '''Simple Data Writer''' was used to produce much friendlier CSV results files. - *JMeter's inbuilt Graph function was not sufficient to process the volume of data. An example of the type of graph required follows. The reader will see that the JMeter test plan produced variations in load (normal, high & spike), and the response times were quite well-behaved. If the integration layer was performing poorly, the graph would show inconsistent throughput and fluctuating response times. - Unix/Linux BASH shell scripts were used extensively for analysis, and preparing data for Excel graphs. + = Summarizing Huge Datasets = + As a software tester, sometimes you are called upon to performance test a web service (see [:../UserManual/BuildWSTest:BuildWSTest]) and present results in a nice chart to impress your manager. JMeter is commonly used to thrash the server and produce insane amounts of throughput data. If you're running 1000 tpm this can be rather a lot of data (180,000 transactions for a 3 hour test run). Even using the '''Simple Data Writer''', this is beyond the capability of JMeter's inbuilt graphics package and is too much to import to Excel. + attachment:throughput-graph.png + + My solution is to group throughput per minute and average transaction time for each minute. Attached below is a script for processing a JTL log file from JMeter. It reduces a 3-hour test run to 180 data points which is much easier to represent with a chart program such as Excel. [[BR]] + The script uses a few neat awk tricks, such as: + [[BR]] + * Rounding unix timestamps to nearest minute + * Collect timestamps grouped by minute + * Convert unix timestamp to YYYY-MM-dd etc. + * Print Throughput for a minute increment + * Print Average response time for a minute increment + * Do all of the above in an efficient single pass through awk (this was the hardest bit!) - attachment:throughput-graph.png [[BR]] - - === Simple Data Writer JTL files === - JMeter's [http://jakarta.apache.org/jmeter/usermanual/build-monitor-test-plan.html Simple Data Writer] produces JTL output files which convey the same information as the default XML output, but the CSV format is much denser. Example: - {{{ - queryBalance.jtl - - timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,bytes,grpThreads,allThreads,URL - 1158477785863,351,SL_queryBalance,200,,queryBalance 1-1,text,true,87,7,7,http://123.45.67.89:8080/WebService - 1158477785953,291,SL_queryBalance,200,,queryBalance 1-4,text,true,87,7,7,http://123.45.67.89:8080/WebService - 1158477785883,431,SL_queryBalance,200,,queryBalance 1-2,text,true,87,8,8,http://123.45.67.89:8080/WebService - 1158477786013,301,SL_queryBalance,200,,queryBalance 1-5,text,true,87,8,8,http://123.45.67.89:8080/WebService - 1158477785883,481,SL_queryBalance,200,,queryBalance 1-3,text,true,87,9,9,http://123.45.67.89:8080/WebService - 1158477786113,331,SL_queryBalance,200,,queryBalance 1-6,text,true,87,10,10,http://123.45.67.89:8080/WebService - 1158477786183,301,SL_queryBalance,200,,queryBalance 1-7,text,true,87,11,11,http://123.45.67.89:8080/WebService - 1158477786404,120,SL_queryBalance,200,,queryBalance 1-10,text,true,87,11,11,http://123.45.67.89:8080/WebService - 1158477786334,200,SL_queryBalance,200,,queryBalance 1-9,text,true,87,11,11,http://123.45.67.89:8080/WebService - 1158477786254,290,SL_queryBalance,200,,queryBalance 1-8,text,true,87,11,11,http://123.45.67.89:8080/WebService - 1158477786474,140,SL_queryBalance,200,,queryBalance 1-11,text,true,87,12,12,http://123.45.67.89:8080/WebService - ... - }}} - - == Excel Throughput Graph == - JMeter's output graph is too granular to depict throughput for extended test intervals (anything from 2 to 24 hours). An Excel constraint its maximum of 65536 rows. So JTL files of ~100k rows should be summarized into increments of 1 minute (or 2,5,n minutes depending on requirements). - [[BR]]For each minute: throughput = count of transactions in that minute ; response time = average of 'elapsed' values in that minute. - [[BR]]The script `jtlmin.sh` summarizes large JTL files into 1 minute increments producing an OUT file that can be imported to Excel and a graph produced. Script: attachment:jtlmin.sh.txt [[BR]] - [[BR]] An example session, using `jtlmin.sh` to process a JTL file. The file produced, `queryBalance.jtl.OUT` (tab-delimited), can now be used to produce throughput graph. Response times can also be included on the secondary axis, as in the diagram above. These graphs were very good at showing when the integration layer was slow to respond and when throughput varied from the original JMeter plan. {{{ $ jtlmin.sh @@ -234, +215 @@ 1160355300 2006.Oct.09 13:55 0 0 1160355360 2006.Oct.09 13:56 0 0 }}} + Script: attachment:jtlmin.sh.txt [[BR]] - === Conversion of JMeter timestamps === + NB, here's a script to convert JMeter's Unix timestamps: Script: attachment:utime2ymd.txt [[BR]] - The first field of a JTL output file is a Unix timestamp extended to milliseconds. The above script `jtltotals.sh` calls another script `utime2ymd` to convert start & end times into year-month-day.hour-min-sec (yyyymmdd.HHMMss). Usually the JTL timestamps are adjusted for your local timezone (eg. GMT plus or minus a few hours). The `utime2ymd` script uses the local timezone by default, but can also provide GMT values -- useful for converting x-thousand elapsed seconds into hhmmss. Example of usage: - {{{ - $ utime2ymd - Usage: utime2ymd <timestamp> [local|gmt] - - Convert 10-digit Unix timestamp to yyyymmdd.hhmmss format - use local time zone (default) or UTC/GMT - - $ utime2ymd 1158477785863 - 20060917.192305 local - - $ utime2ymd 3601 gmt - 19700101.010001 gmt - }}} == Java Class to Quickly Summarize JMeter Results == --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
