Sun released Java SE 6 Update 14, which included a version of the much-anticipated Garbage First (G1) garbage collector. G1 is a low-pause, low-latency, sometimes soft real-time, collector that allows you to set max pause time goals and collection intervals through suggestions on the Java VM command line. Although it cannot guarantee it, G1 will attempt to meet your goals, and hence introduce as little latency as possible into your application. This in turn may also make the VM run more predictably as it attempts to meet the pause time goals you provide.
Garbage-First is a server-style garbage collector, targeted for multi-processors with large memories, that meets a soft real-time goal with high probability. It does this while also achieving high throughput, which is an important point when comparing it to other real-time collectors.
The G1 collector divides its work into multiple phases, each described below, which operate on a heap broken down into equally sized regions. In the strictest sense, the heap doesn't contain generational areas, although a subset of the regions can be treated as such. This provides flexibility in how garbage collection is performed, which is adjusted on-the-fly according to the amount of processor time available to the collector.
By – Chaitanya
Open Source Load Testing Tool for Java Applications (JMeter)
This is an Ant task for automating running JMeter test plans. The task executes one or more JMeter test plans, and logs the results to a file.
To use the task, you must have JMeter installed. You must also include ant-jmeter-1.0.9.jar in your Ant class path. Adding the jar to $ANT_HOME/lib will make this happen automatically.
Start by defining the task to make it available to your build script:
classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"/>
Set the jmeterhome parameter to your JMeter install location, and the resultlog parameter to the name of a file to log the test results to.
You can either specify a single test plan using the testplan parameter, or multiple test plans using the testplans nested element. The testplans element is a standard Ant FileSet element.
testplan="${basedir}/loadtests/JMeterLoadTest.jmx"
resultlog="${basedir}/loadtests/JMeterResults.jtl"/>
resultlog="${basedir}/loadtests/JMeterResults.jtl">
Optional JMeter arguments supported include specifying an alternate jmeter properties file (jmeterproperties), running remote servers specified in jmeter properties file (runremote), and running the tests through a proxy or firewall (proxyhost, proxyport, proxyuser, proxypass).
Setting the failureProperty attribute will set the specified property to "true" in the event of a JMeter test failure. This gives you the opportunity to take further action such as send an email or fail the build.
You can override JMeter properties (instead of modifying jmeter.properties) like this:
testplan="${basedir}/loadtests/JMeterLoadTest.jmx"
resultlog="${basedir}/loadtests/JMeterResults.jtl">
You may also specify additional JVM arguments to the JVM launched to run JMeter. Here is an example of how to specify JVM arguments:
testplan="${basedir}/loadtests/JMeterLoadTest.jmx"
resultlog="${basedir}/loadtests/JMeterResults.jtl">
I've also included an XSLT file, jmeter-results-report.xsl, for generating a summary report from the result log file. The summary report is very similar to the default report created by the junitreport task. You can use the xslt task to create the report:
out="${basedir}/loadtests/JMeterResults.html"
style="${basedir}/loadtests/jmeter-results-report.xsl"/>
Note: If you are using JMeter 2.1 or later, you must use the new xslt stylesheet(s) included in the JMeter extras directory. The new stylesheets have been modified to support the new JMeter log file format.
If you would like failure detail messages in the report output, you must configure JMeter to output that information to the result log. To do this, set the following property in your jmeter.properties file before running the test plans:
jmeter.save.saveservice.assertion_results=all
Note: As of JMeter 1.9RC2 (?), the default results output format is now csv. It must be changed to xml in order to use the xslt task to create the html report
By – Bavan
How to improve Java's I/O performance
The JDK 1.0.2 java.io package has meant problems for I/O performance, but here's a tip for making the situation better -- plus an extra tip on turning off synchronization
Java's I/O performance has been a bottleneck for a lot of Java applications because of a poorly designed and implemented JDK 1.0.2 java.io package. A key problem is buffer -- most classes in java.io are not buffered. In fact, the only classes with buffers are BufferedInputStream and BufferedOutputStream, but they provide very limited methods. For example, in most file-related applications, you need to parse a file line by line. But the only class that provides the readLine method is the DataInputStream, and it has no internal buffer. The readLine method in the DataInputStream class actually reads the input stream character by character until it hits a "\n" or "\r\n". Each character-read operation involves file I/O. This is extremely inefficient when reading a large file. A 5-megabyte file requires at least 5 million character-read file I/O operations when no buffer is provided.
The new JDK 1.1 improves I/O performance with the addition of a collection of Reader and Writer classes. The readLine method in BufferedReader is at least 10 to 20 times faster than the one in DataInputStream when a large file is encountered. Unfortunately, JDK 1.1 does not solve all the performance problems. For example, RandomAccessFile is a very useful class when you want to parse a large file and do not want to read it into memory. Still it is not buffered in JDK 1.1, and no equivalent Reader class has been provided.
By – Arun GJ
Please find more topics under JASe Archive!!!
No comments:
Post a Comment