|
|
|
|
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
