Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
JProfiler: Get rid of your performance problems and memory leaks! 

The Interview: Kirk Pepperdine

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:



JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 029 contents

Kirk Pepperdine is our Roundup columnist, lurking and occasionaly thrusting answers into discussion groups. Behind the scenes, Kirk contributes more to the JavaPerformanceTuning.com website, and this month, we took some time from his schedule to ask him some questions.

JPT: Tell us a little bit about yourself.

Kirk: I started my career as a Biochemist. I wasn?t all that good at biochemistry but I managed to get interesting jobs because of my abilities with computers. At that time, small computers were just finding their way into laboratories. So, after a brief stint as a Biochemist, I returned to school just in time to be included in the first stream of a CS program that was focused on OOP. After that, I started working with large distributed systems and in the process was part of group that introduced objects into an organization in the Canadian government. That organization had a real focus on application performance, something that I found very appealing. It was originally a bit of a culture shock to move to industry and find that ROI concerns drove performance to a secondary status. ROI is much more measurable in industry then it is in research and the focus switches from that of discovery to one of profit.

JPT: How did you come to be involved with JPT.

Kirk: It all started when Jack and I were engaged to performance tune a banking application. During that time, Jack and I combined our experiences to devise a process to follow. We found that the dynamics of the environment forced us to not only plan for technical challenges but for managerial challenge also. At the beginning, there was the usual mindset that tuning would just somehow happen. Once that process failed, Jack and I were able to put forward the plan which to their credit, management accepted with a fair degree of enthusiasm. From this experience, Jack was able to provide what I believe is the differentiating material between his and all other performance tuning books that I?ve read. That material covers management aspects of planning for performance. When Jack started the website and subsequently, the newsletter, I was only too happy to contribute in some small way. More recently, Jack has allowed me to take a bigger role helping him revamp the site and to create a number of specific services that focus on helping organizations build high performance applications and/or do more work with fewer resources.

JPT: What are the most common problems that you see organization struggle with as they attempt to scale their application?

Kirk: Well, this is a multi-faceted question. Let me start by saying that most organizations that I?ve had involvement in have the raw talent to produce efficient applications, though I must emphasize the adjective raw. Another factor is focus. Those most capable of performance tuning an application are often those whose overall skills are already in high demand by the organization. Thus, they are not readily available to performance tune an application unless the situation is critical. Even if the resources are available, they often lack the experience to properly plan for an exercise which they often under-estimate the size of the task and only discover after starting that they need resources that they don?t have, have not budgeted for, or otherwise will have difficulty obtaining. Another facet is having staff that have an understanding of the specific products being used. In fact, Candle just recently held a webinar in which they polled the (well over 100) attendees as to what the most their most pressing concern was. More than 54% responded that lack of product specific training was their number one concern. With the push to development business requirements being what they are, it is understandable why it is difficult for application programmers to find the time to learn about a specific application or environment to the extent required to technically tune a complex piece of software such as a relational database or an application server.

JPT: So, you don?t feel technical problems are a risk factor?

Kirk: For sure technical obstacles are at the root of the risk. But, with everything, the exact level of risk depends upon the capabilities of the person dealing with them. This is where training and experience come into play. For a manager to be able to mitigate risk, he first has to recognize that risk. If the experience level is low, then it becomes difficult to filter out real from perceived risk. Some of that can be made up with training but as helpful as training can be in jump-starting a process, having the right experience can make a bigger difference.

JPT: In your years of performance tuning, have you seen a change in the technical risk factors?

Kirk: Well, yes and no. I?ll address the no answer first. In the number of years that I?ve been addressing performance problems, the underlying technology has basically looked the same. You?ve got bits of memory, each with a different associated cost of storing and retrieving data. This ranges from I/O devices such as networks, disk drives, tape drives to SSD, and various types of random access memory up to on-CPU cache memory. Though the size and access speeds have changed on all of these devices, they still suffer from about the same rates of latency in relation to each other. In the case of the CPU, we?ve seen a dramatic increase in speed relative to the increase in drive speeds. At any rate, all of these physical devices represent scarce (or expensive) resources and this has not changed all that much. On the yes side, we?re now seeing much more sophisticated use of hardware. ASIC technology is now cheap enough for it to be economically embedded into price sensitive consumer electronics. Things like FPGA and Xlinx?s chips allow one to move critical functionality down to a hardware level without having to incur the expense of running a Fab. But, this technology is still pretty exotic. From a software perspective, to this day, Fortran compilers are still regarded as the best for scientific computing. I remember when Cray started producing their C compiler. The memory management headaches lead to some interesting performance problems, which they had to resort to using pragma to solve. This required that the programmer, which in many cases were primarily mathematicians, to have a very strong knowledge of the underlying hardware. I think that it?s generally accepted that people don?t want to have to understand when your code may cause excessive instruction buffer faults. To write a large business application in C required a level of expertise that is just difficult to come by. This is but one of the reasons that Visual Basic has been so successful. With the general acceptance of Smalltalk, it looked as if the business community had finally found the elusive environment they had been looking for to replace creaky Cobol. It was quite interesting to watch Java knock out it?s growth curve before it reached escape velocity. From a programming point of view, I still prefer the normalized view that Smalltalk presents, but Java introduces a number of concepts that were lacking in Smalltalk. They also both use a virtual machine which further removes your application from the hardware. So, as each technology has been introduced, it has solved some problems and quite naturally, supplanted others with it?s own.

JPT: What are you personally bringing to Java Performance Tuning?

Kirk: Actually nothing. What I am doing is injecting a new energy into things that Jack and I have been discussing for a couple of years. Our different career tracks have prevented us from really developing these ideas. Though I said nothing at the start, at the moment, it?s difficult to ascertain who?s developed what. This is because Jack and I have enjoyed a certain synergy that has allowed us to take each other?s ideas to that next level. From that standpoint, it?s been a very enjoyable working relationship.

JPT: What do you hope to achieve with Java Performance Tuning.

Kirk: There are so many things to be done that it?s hard to remember that one can?t do it all. First and foremost, I would like to create a forum in which I can continue to do what I really enjoy doing, providing reductions that allow applications to scale. If I can do this, then I know that Java Performance Tuning can grow into an organization that can make at least a small difference in the industry. Jack and I see this coming though the introduction of boot camps, training courses, mentoring and plain old getting our hands dirty rooting around in code and environments. The first step is a revamping of the website. Right now the only commercial look is the three sponsor slots that are used to help offset the costs of running the site. Though Jack and I are very concerned about maintaining the site?s unique character, we feel that in order to support our greater vision, we need to institute some changes that reflect that vision. Having said this, Jack wrote an open letter admonishing JavaWorld for closing their archives (they subsequently reopened them). In that letter Jack pledged to keep JavaPerformanceTuning.com open, and to keep adding fresh material to it. We are both totally committed to maintaining that pledge. So, although the site?s look and feel will change a bit, it will still be totally open as it is today.

JPT: You mentioned boot camps. What are they?

Kirk: Boot camps are a mixture of course material and lectures. The idea of a bootcamp is to use mentoring to reinforce materials delivered in short more traditional course environments. The difference here is that students get a real chance at understanding a lot more of the material than they normally would. In a standard course, material is presented; hopefully about half really understand what is going on and the rest struggle. This is not to say that courses are bad, it?s just that learning takes think time. By stretching out the training session and reinforcing it with on-site mentoring, we can achieve a much greater boost to a team.

JPT: So, you don?t see traditional courses as being effective?

Kirk: I wouldn?t say that they are not effective, they are just not as effective as a format where the material is reinforced. Having said this, the traditional course format has its uses. For one thing, traditional courses are effective in situations where mentoring is impractical. Certainly I prefer the boot camp approach to training but, there are many situations where a traditional course is best.

JPT: In addition to training, you talk about service products. Can you tell me a little about the ideas behind these products?

Kirk: After doing a number of tuning engagements, you start to see patterns develop. The tuning service products take advantage of these patterns to provide managers with something they understand. After all, tuning is a voyage of discovery. You profile, see what?s wrong, try to figure out why it?s that way, and then embark upon fixing it after which you need to repeat the process until the performance characteristics are within tolerance. This is the equivalent to a while (! fast enough) loop. So, how many iterations will it take for the exit condition to be meet? It?s often a difficult question to answer, something that managers don?t like to hear because it means we can?t predict something, and therefore we can?t really control it. In other words, it's a risk that we don?t know how to assess. What the service products do is try to provide a bound for the time frame. Because we have experience doing this over many projects, we can take advantage of patterns we?ve seen. Most project teams simply lack the number of data points required to fetter out these patterns.

JPT: Do you see yourself pushing out into any other areas?

Kirk: As a matter of fact yes. I have just started an effort to build a tool with the help of another developer that I?m pretty excited about. It should really allow one to get a unified look at the entire Java runtime environment. But you'll have to wait a little while before I give out the details on that tool. When it's ready, you'll find it at JavaPerformanceTuning.com.

JPT: Thanks for you time. (End of interview).


Back to newsletter 029 contents


Last Updated: 2017-11-28
Copyright © 2000-2017 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.
URL: http://www.JavaPerformanceTuning.com/news/interview029.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us