I like this
thread. Here are some random thoughts in no particular order:
1) Measure don't guess - Often we guess wrong on what code to tune and end up wasting our time tuning code that makes no overall impact. Measure performance and go for those small sections of code that consume the most time. Measure your performance improvements and repeat the process.
2) Measure in production - You have no idea how your system is used unless you are looking at real user interactions. For example say you have 2 pages that each take 1 second to execute. In load tests you assume that each page will be hit the same number of times, but users think otherwise. Users may hit one of the pages orders of magnitudes more than the other one. By measuring in production you learn which page should be tuned first. Usually master pages are hit more than detail pages.
3) Build performance measurement collection into your application from the start - Web performance is difficult to understand looking in from the outside. Measure overall page response time and calls to external systems like
jdbc (see the jamon
servlet filter mentioned below)
4) Use the JAMon servlet filter, it is your friend - I must admit I wrote this software and so I am biased, but by simply adding a few lines to your web.xml and making jamonadmin.jsp accessible you get many performance statistics such as: page hits, avg time, min time, max time. You also get concurrency stats like which pages are currently executing, what were the max simultaneous invocations per page. You also have correlations between performance and concurrency i.e. this is a measure of scalability.
A few more things. JAMon is fast enough to be used in production systems (pretty much no overhead), it is part of your app so no special installation of software, it can monitor other things such as jdbc too, and it is free. Because JAMon is part of your application it moves from dev/test/prod with no server environmental changes.
To see a live demo go to:
http://ssouza.kgbinternet.com/fdsapi/JAMonAdmin.jsp 5) It's probably the database - A recent application that I worked on took 95% of its execution time executing SQL. Of the 50 or so sql statements 80% was spent on 2 queries. These queries were tuned by adding indexes and the application zipped along with NO code changes. Only 5% of the application was doing anything in java code. I find this to be pretty typical. By the way your denormalized database can often not perform as well due to having fat tables that must perform more IO. Indexes are your friends.
6) If it's not the database it is probably some other IO - IO (database, network, file) will usually be your performance culprits, and not your java code. Tuning your jdbc driver, and network may help more than tuning your java code.
7) Learn to write good SQL - This is probably more important than any Java P&T tricks you can learn.
8) Some performance truisms:
- 80% of a programs execution time is caused by 20% of the code. Your job as a tuner is to find the 20% of your code and leave the other 80% alone.
- "More computing sins are committed in the name of efficiency than for any other single reason-including blind stupidity" - W.A. Wulf
- "...premature optimization is the root of all evil." - Donald Knuth
9) Be wary of slow home pages - Home pages are often heavily hit. Have them due minimal work or even just display a menu. One app I work with has a home page that takes 2 seconds, but I am never interested in that page and immediately go elsewhere.
10) Don't microtune - An example of microtuning is when you have a page that takes 1 second to execute, and you notice that you can make a piece of code that takes 20 ms. down to 10 ms. You've double the performance of this code which sounds impressive, but have trimmed performance of your overall page a trivial ammount (from 1000 ms. to 990 ms). This tuning was a waste of time. Your time would have been better spent drinking a beer. Look for changes that give you the biggest bang for your tuning buck.
11) There are bad Performance Tuning Questions - The most common performance tuning questions I see on the java forums, are purely academic and make no substantive difference in a real program. Questions like: "Are statics faster than instance variables?", "Are local variables faster than instance variables?", "Are HashMaps faster than Vectors?", "Are while loops faster than for loops?",...
12) It's not average execution time but total time - If you don't know the frequency of execution (hits) then you wouldn't know which page to tune of 2 pages that take 1 second to execute. If you know one is executed 10 times a day and the other 10,000 times a day you would.
13) Good design is your best performance tuning tool - Good designs are easy to change and so easy to make faster. Good design involves having a way to measure application performance.
14) If your page takes more than a couple seconds it probably needs tuning - Users are that patient and will move to another site or start mashing on the refresh button if your page is slow. Both outcomes won't be to your liking.
15) Your biggest scalability problem may be one user getting impatient and hitting refresh before the page returns - In applications I have seen users have many many outstanding requests and so one user can single handedly bring your site down unless you build protection for this into your app from the start. (The JAMon servlet filter can detect this problem)
16) Don't return 10,000 rows - The bad news is browsers are slow in displaying so many rows. The good news is that your users really don't want to see so much data even if they say they do. It is your job as a developer to find out what they really want and give that capability to them.
17) Java is fast, very fast - Despite java's still lingering reputation of being slow it is very fast. I can execute a method on my old clunker pc 60,000,000 times a second. Even object creation and garbage collection are quite fast.
18)
www.javaperformancetuning.com 19) Google is your best friend - Google knows anything you wish to learn about performance tuning and any other topic
[ September 12, 2005: Message edited by: steve souza ]
