[an error occurred while processing this directive]
Java Performance Tuning
Java(TM) - see bottom of page
Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks!
Training online: Threading Essentials course
Tips September 2008
Get rid of your performance problems and memory leaks!
Get rid of your performance problems and memory leaks!
Back to newsletter 094 contents
Testing for performance, part 1: Assess the problem space (Page last updated February 2008, Added 2008-09-29, Author Michael Kelly, Publisher TechTarget). Tips:
- Ask: What are the various applications, data sources, services and protocols in the system? What do the network and hardware infrastructure look like? What do the use cases and business workflows look like?
- Questions to answer on the application include: What applications and services are there, including external dependencies; Where is data stored and read from and in what formats; what software processes are there; detail differences between production and test environment; any licensing issues or data limitations.
- Questions to answer on network and hardware infrastructure: list servers and appliances/devices, and their connections, specifications and configurations; Where and what kind of load balancing; detail differences between production and test environment.
- Questions to answer on the system: Who uses this system and why; What types of transactions take place; any calendar-based transactions (end of day, monthly, yearly, etc.).
- List key metrics that will be helpful when it comes to tuning or debugging (e.g., memory/CPU usage, database calls, live sessions versus active sessions, etc.).
- UCML (User Community Modeling Language) is useful for depicting test plans.
- Start with the end user in mind when planning performance tests: what will the user do with the software; what types of transactions do they care about; what time of day will they do it; what needs to be set up in the systems for them to be successful; etc.
- Not all performance testing is focused on the end-user response time, sometimes resource utilization and throughput specified in transactions per minute and percent usage are targets.
- Increase the number of users with each successive test with the end goal of showing a graph of response time (y) versus number of customers (x).
- You should have an understanding of the system you're testing; you should have a strategy for approaching the problem, along with a rich set of test ideas to prioritize and work from.
Testing for performance, part 2: Build out the test assets (Page last updated March 2008, Added 2008-09-29, Author Michael Kelly, Publisher TechTarget). Tips:
- Selecting data based on risk: most frequently used (login ids, reference data, etc.); most intensive (wildcard searches, large file uploads, values requiring conversion, etc.); Business critical (month-end processing, creation of new accounts, etc.); Legal; Obvious: will earn a bad press if they fail; # Technically risky (places where it has failed before, etc.); Stakeholder-mandated: been asked/told to test.
- Selecting data based on test scenarios: what data do you need to exercise each test role - make sure data variety is considered.
- Selecting data based on availability: You may want to select data that's readily available. This could be production data, data from past iterations, spreadsheets used by manual testers, data from other projects, or data from some data generation source.
- You can't average ninetieth-percentiles of each scenario to get the ninetieth-percentile for the run. If you want that, you should aggregate your timers. Otherwise you'll need to go back to the raw data and build your aggregate numbers from there.
- Create a scripting checklist that reminds you of everything that needs to be done after you record your scripts - Whatever you find you need to do on a regular basis.
- Calibrate your tests - use key metrics to compare against production or requirements to make sure they are doinf what you think they are doing.
- Common metrics used to calibrate performance test scripts include: Transactions over a period of time; Concurrent live and active sessions; Percent connection-pool utilization, CPU utilization, memory utilization and average queue depth.
- Calibrating performance tests include the following: Changing your think times and delays; Changing the number of users in the test or changing usage model percentages; Changing your user ramp up time; Changing the number of iterations and time between iterations; Changing the test scenarios or test data;
Testing for performance, part 3: Provide information (Page last updated April 2008, Added 2008-09-29, Author Michael Kelly, Publisher TechTarget). Tips:
- Try to ensure configurations are as expected for all tests, preferably with automatic checking scripts
- While tests are running, it is helpful to monitor their execution - if there's a problem, you can often notice it soon enough to end the test run early and start it up again
- It can also be useful to watch streaming application logs, performance test data usage, and performance monitoring applications and utilities - sometimes you'll find patterns while data is streaming that you may not see once you've collected it all and start analyzing it statically.
- For analysis, first look at errors, and account for them, then transactions frequency and timing. After that look at basics such as CPU and memory utilization for each sever involved, and move on to things like average queue depth and average message time spent in queue and how load balancing was distributed for the run, looking for anything that might be out of tolerance. Finally analyze the transaction response times.
Efficient data transfer through zero copy (Page last updated September 2008, Added 2008-09-29, Author Sathish K. Palaniappan Pramod B. Nagaraja, Publisher IBM). Tips:
- Zero copy lets you avoid redundant data copies between intermediate buffers and reduces the number of context switches between user space and kernel space.
- Applications that use zero copy request that the kernel copy the data directly from the disk file to the socket, without going through the application.
- The Java class libraries support zero copy on Linux and UNIX systems through the transferTo() method in java.nio.channels.FileChannel. You can use the transferTo() method to transfer bytes directly from the channel on which it is invoked to another writable byte channel, without requiring data to flow through the application.
The Law of the Uneaten Spinach (Page last updated May 2008, Added 2008-09-29, Author Dr. Heinz M. Kabutz, Publisher ). Tips:
- Deadlocks can occur when two threads are locking on two different locks, in opposite order. Usually this happens inadvertently. The deadlock can occur between two monitors or between two locks or a hybrid of the two.
- Thread.stop can interrupt and terminate a thread in the middle of a synchronized block, causing the block to fail to complete and so leaving the data state in a potentially inconsistent state (violating the atomicity of the block)
- You can interrupt a deadlock and exit cleanly - the best approach is to always use Lock.lockInterruptibly() and also Lock.tryLock().
- Thread.stop() does strange things to threads deadlocked on monitors - it actually breaks the deadlock detection mechanism in Java.
- The only locking mechanism that manages to recover from a deadlock situation cleanly is the Java 5 Lock.lockInterruptibly.
- Interrupting deadlocked threads is a bit like putting a band aid onto a gaping wound. It might buy you time and keep your system limping along for a bit more, but should not be seen as a long-term solution.
Matching Wildcards: An Algorithm (Page last updated August 2008, Added 2008-09-29, Author Kirk J. Krauss, Publisher DrDobbs). Tips:
- It is difficult to guarantee recursive algorithms are bounded in the stack.
- [Article presents a non-recursive fast & simple string comparison algorithm that handles simple wildcards].
Using P6Spy and the GlassFish Connection Pool to Trace Database Operations (Page last updated July 2008, Added 2008-09-29, Author Jagadish Ramu, Publisher Sun). Tips:
- Tracing database operations can help you fine tune the database calls.
- P6Spy is an open source Java tool that intercepts and logs all database statements in an application that uses Java Database Connectivity (JDBC).
Back to newsletter 094 contents
Last Updated: 2019-08-29
Copyright © 2000-2019 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us