《JAVA应用软件最优化.doc》由会员分享，可在线阅读，更多相关《JAVA应用软件最优化.doc（17页珍藏版）》请在三一办公上搜索。
1、毕业设计外文资料翻译（译文）题目名称： Optimizing Java Applications 学 院： 计算机科学技术 专业年级： 计算机科学与技术（工）07级 学生姓名： 徐 洋 班级学号： 1班32号 指导教师： 张淑英 二一一 年 三 月 十五 日译文题目： JAVA应用软件最优化 原文题目： Optimizing Java Applications 原文出处： Database System Implementation Optimizing Java Applications Use sound practices to make code-and development tea
2、ms-more efficientWithout the right tools and techniques, tuning for performance can be unbearably difficult, yet you cant afford to turn your back on the process. Its absolutely critical. With the size and complexity of most Java applications, its getting much more important to get an early handle o
3、n performance. Gartner estimates that only 14% of applications meet all measured and tested response time estimates. Lets consider a true scenario. A development team works on a complex, proprietary application designed to automate the scheduling and loading of railroad freight trains. After the dev
4、elopment cycle, they performance test the application during a planned tuning cycle, and then they begin to get into trouble: They find that they must make sweeping design changes to satisfy performance problems, which will result in major architectural upheaval-theyve waited too long to test. They
5、waste time on a cache that has no bearing on performance-theyve set their priorities incorrectly. The team discovers memory leaks, but the manual detection and troubleshooting cost the team weeks-theyve neglected investment in good tools. When all is said and done, the project is delivered $240,000
6、over budget and more importantly three months late. This story is repeated with increasing regularity across many J2EE development shops. The problems are severe, and also frequently preventable. In this paper, well talk about some ways to move performance out of an inefficient box at the end of the
7、 cycle, and into the fabric of your everyday routine. Whats Wrong?Before looking at effective ways to tune, lets consider some common tuning practices that dont work. At least one of these potential traps plague the vast majority of Java developers: Neglecting tools. Without the right set of tools,
8、you dont have a fighting chance. Solving a single tricky memory leak without supporting tools will often cost your employer more than the price of a good performance tool, based on labor and delayed deployment costs. Throw in abilities like profiling and threading support, and the right tools go fro
9、m the realm of luxury to essential, but developers and managers alike neglect this area with frightening regularity. Setting priorities incorrectly. Work on the right performance problem at the right time, and youll be a highly effective tuner. Many developers still try to optimize every line of cod
10、e as they go, a tremendously inefficient philosophy. Others neglect performance until the end of the cycle, when critical structural changes are all but impossible. We can improve dramatically on both of these approaches. Many managers fear placing too much emphasis on performance too soon, yet this
11、 fear is often misplaced. Proponents of agile development processes have successfully demonstrated the benefit of continuous integration, so much so that it is working into mainstream development methods. Many programming books like Kent Becks best-selling eXtreme Programming Explained provide hard
12、evidence supporting continuous integration, claiming that integration costs increase exponentially with delay. When you think about it, poor performance is often a symptom of an integration problem. Gone are the days when performance optimization meant tweaking a couple of lines of code in a single
13、method. Today, performance relates primarily to how components work together, across frameworks, applications, components and distributed systems. Threading, memory management and distributed communication are the new realms of performance tuning. Said another way, performance has largely become an
14、integration issue, and should be attacked at the earliest possible moment. If you can attack performance problems before they have a chance to fester, you dramatically reduce the time that it takes to solve them. With time, they grow in scope and complexity. A better performance process, then, shoul
15、d let you detect problems as early as possible. At first, this goal can sound impractical, but many teams already have the right tools in place to get the job done. How Should You Tune?The fundamental key to a sound performance process is setting priorities effectively, so automation is critical to
16、your success. The best way to automate is to expand your regular unit tests to also include performance tests. JUnit is an open source automated testing tool, and is a widely accepted framework for unit testing. If youre already using a tool like JUnit, youre halfway there. In short, your system wil
17、l automatically measure performance and notify you when a performance test case fails. You can then immediately fix the problem at the time its introduced. To inject performance tests into an existing test suite, you merely need to do the following steps: 1. Define performance requirements. 2. Add y
18、our automated performance test suites. 3. Make the fix. If youre like many developers, you probably invest most of your effort on the third step, even though you havent nailed your specific problem. We shift most of that effort into building reusable test cases that repeatedly warn you when performa
19、nce wanders out of an acceptable range. Lets address each of these steps in more detail. Step 1 Define Performance RequirementsWhen you gather requirements for an application, youll often be working from a use case, which is a task that a user wants to accomplish with your system. For each use case,
20、 you should make sure that you understand any performance requirements. Does your scenario require immediate response to an end-user, or a batched set of reports with no hard performance requirement? Is the user in an internal call center with a customer, or possibly an Internet customer? How many s
21、imultaneous users are expected on average and at peak times? By gathering performance criteria for each major use case, youll have some hard data that you can use to manage the rest of the process. Remember, no application is perfect: you can always optimize. For efficiency, you should do precisely
22、enough to meet the requirements of your customer. You may well make a conscious decision to over-deliver, anticipating possible future scalability requirements. You can always build in more stringent requirements into your test cases. Step 2 Automate Performance TestingMany development teams use the
23、 Agile programming practice of writing test cases before the rest of the code. The benefits are well documented, so well not repeat them here. You know youre done when you satisfy the test cases. Its the responsibility of each developer to code and maintain a working effective test suite. You should
24、 add performance requirements to your test cases. If you use JUnit, you can use a JUnit extension like JUnitPerf (discussed below) to add your performance tests. By adopting automated test suites, you can safely work performance optimization into your everyday routine, without the danger of setting
25、priorities incorrectly. Remember: the purpose of your performance tests is to warn you when your codes performance creeps out of accepted tolerances. When that happens, you can drop what youre doing and drill down with your performance tool to profile and solve your performance problem. With this pr
26、ocess, you will greatly reduce your dependence on any special tuning process or team. Poor performance can be handled just like any other bug. Test scalability and response timeWell hit the bare highlights of performance test construction here. You want your test cases to handle simple measurements
27、for response time, and complex measurements of scalability. Response time is simply the time between the start and end of a request. Scalability measures the number of requests that your application can handle simultaneously. These tests measure each type of performance. Timed tests. check the respo
28、nse time of a single method or use case. You can build your timed tests to run a single test, or run multiple tests, and take an average. You can also build your timed tests to disregard early iterations through a test. Either way, you must make sure that you discard the overhead for setting up the
29、test. (In most cases, the time is negligible, and its often measurable.) Load tests. check the scalability of the system under the load of many simulated users. Youll probably want to accumulate several timed tests into a test suite. Your tool should let you simulate the user community, whether they
30、 are randomly distributed or evenly spaced. You may want to run your tests at different intervals. Basic timed tests can run with the rest of your JUnit suites. Since load tests take longer, you may want to run that test suite less frequently. You may also wind up adding some requirements that test
31、resource usage over time, like memory. Some of the better performance test tools allow you to automate this type of testing as well. If yours doesnt, periodic manual tests will do. Run your tests throughout the cycleRather than running all of your tests at the end of the cycle, this process calls fo
32、r running your automated tests throughout the cycle. Most teams have their JUnit test cases create a test report after every automated build. This way, youve got an accurate picture of what your system performance looks like at any point in time. Remember to address performance as you go. Your use c
33、ase is not completed until all of your test cases successfully run. You will find that adding performance tests to your automated test suites is an incredibly liberating experience. By coding the test cases, youll be able to run them throughout the development cycle-not just the end. Youll catch pro
34、blems early as theyre introduced, and while they are easy to solve. Step 3 Make the FixNow that youve identified the areas of your application that need attention, you can finally optimize the scenario. The role of your test suite is to identify what you need to fix, when you need to fix it. Instead
35、 of trying to optimize everything, you optimize exactly what needs it. Try to choose simple algorithms that work, and spend time on optimizations only when they dont meet your performance requirements. Instead of waiting until the end of the cycle, you improve performance on an every-day basis, when
36、 problems are introduced. You do precisely the right amount of work on performance-nothing more, nothing less. You can make design improvements earlier in the cycle, when user requirements dictate that you do so. The result is gratifying. Your customers get faster applications, in less time. The see
37、ming paradox is that by adding performance work into your everyday routine, you will become much more efficient overall. What do you Need to Succeed?You probably already know that good performance tools are the secret to effective optimization. Its just too expensive to do business . Currently, Newp
38、ort Group estimates that the average amount of time required to solve a performance problem, from the time that the problem ticket is opened, at 25.8 hours. With compressed budgets and increasing expectations, thats insanely expensive. To have any hope of success, youve simply got to beat the indust
39、rys average, and find the problems faster, and before they leave your protected development environment. Invest in tools that support automation and optimizationOur process defined two major phases of optimization: identifying the problem, and fixing the problem. Both phases need supporting tools. Y
40、oull need specialized tools to help you manage performance, and youll want tools to help you identify problems at both development and post-production time: Youll need a tool that supports performance unit tests. If youre using JUnit to automate your test cases, you can use a simple extension like J
41、UnitPerf to implement your performance tests. Youll need a tool to profile and debug your performance problems. For example, Borlands Optimizeit Suite supports your optimization after you find a problem. Your tool should be able to quickly profile your code for a scenario, and drill down into proble
42、m areas like memory management and thread interaction. Youll need operations tools, like Precices InDepth and Insight, that allow you to keep measuring an application post-production. This tool fills the role of automated unit tests, but after youve moved into production. With so much data and exper
43、ience clearly available about the cost of performance problems and the impact of optimization tools, its amazing to see how many organizations neglect to properly equip their development teams. As frameworks grow in complexity, that practice will simply have to change, as teams wont be able to remai
44、n productive without them. At its core, tuning is effectively gathering and using information. Lets look at three specific areas where an optimization tool can make your life easier: profiling code, solving memory leaks, and optimizing threads. Start with a profilerAfter your test cases have shown t
45、hat you have a scenario with a problem, your first step is to profile the scenario. Your tool will add up the cumulative execution time in each method of your code. As you know, a profile is not a flat list of methods: each method usually calls many others. Tools with good profilers let you drill do
46、wn graphically, and find the coding sections that are requiring the most time. For example, if you find that an unhealthy amount of time is spent dealing with string manipulation, you know that you should tweak the algorithms that build or manage strings. If, instead, you find that most of the time
47、is spent on communications-related activities, then youve probably got to reduce the number of network round-trip communications, possibly through a cache or a session facade. In any case, the profiler alone can often provide enough information to help you rapidly localize and solve your problem. So
48、lve memory leaksSome problems are especially hard to track manually, because they are outside of an applications sphere of control. The garbage collector and heap are usually hidden to the application, but performance tools designed to find memory leaks can watch heaps and trigger garbage collection, giving you enough control to solve the problem. Java virtual machines automate memory allocation, and use a technique called reachable objects to do garbage collection. An object is reachable if you can acces
