Performance - Part 4
March 26, 2009 · by Kevin Runde
Performance Tuning – So why is it slow
So now you have some data (from your tests) and you know what the data should tell you (your goals and other’s expectations). If you are still reading this then your data is probably not where it should be. So, what do you do? How do you succeed? I use a scientific method. First, you take your data and you identifyONE and only ONE problem point. Sit back, think about what may be causing it, but DO NOT CHANGE THE CODE TO FIX IT YET! See if you have data that shows you what is going wrong. Remember, you should have more than one metric to show you exactly where the problem is. If you don’t have enough metrics, then add more. This is where Meta Programming, AOP, and Dependency Injection are very valuable. I want to have the least impact on the code.
So, now you have data that tells you exactly where the problem is. There are probably several things that could be causing the problem. DONOT FIX THEM ALL AT ONCE. Fix one and only one. Test it several times to prove it is fixed. Then, undo that change and prove it is broken again. Then put the fix back in and validate that it still works. Yes, this means you are going to be doing a lot of tests. Welcome to science. To me, this is where programming really is a science. You need to treat it as such, which also means communicating all of your data. Saving all of your data and being able to compare test runs against any other test run. Excel can work wonders here or create a small database app that can read in all of your performance data and analyze it. Have it write out to Excel so that you can generate graphs or a command line graphing tool like GNUPlot. Yes, writing that app will take a bit, but you will be doing so many tests that it will pay out in the long run. It’s not just the amount of time it will save you, either. It will reduce errors and allow you to stay focused on the big issues. During this time, I often find myself climbing into my own little world and only dealing with others when I need something from them. When you realize that you are doing that, stop. Get up and go find someone to talk to for a while. Go read /. or something. When solving big problems like this, you often need to walk away from the problem for a while before your find the answer. If you want to understand this more, I recommend The Pragmatic Programmers book Pragmatic Thinking and Learning: Refactor Your Wetware. It explains why you need to get out of your L Mode. If you don’t know what that means, then read the book.
So, which problem do you try to fix first? The one that is taking up the most amount of time, of course. Oh, sure, you agree with me now, but too many times I have seen people say, “Well I don’t know how to fix that one yet so I’ll go solve these little problems with caching right now. That is a simple change to my Spring Config.” DONOT DO THAT! Once you have fixed your biggest problem the application will behave differently. Those changes you were going to do before may not be needed now. Remember, this is real science and science takes time and does not respect a time line. So, don’t waste your time on changes you may not have to make, or worse, introduce new bugs or performance issues. Remember, performance tuning is like Ogres and each layer can be a vastly different Ogre. Don’t be afraid to do big massive changes to the system. Just don’t do them unless you have a lot of data to back up the decision. You should have designed the system so that you can make changes easily. You also should be able to tell management how confident you are in the change based on the data you have.
Next time, I’ll talk about the side affect of being scientific, and being human.
-Kevin
Filed in: Team Member Blog Comments (0)
Comments
There are no comments for this entry.