-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Alec,
On 8/1/13 6:08 PM, Tomcat Random wrote: > Thanks Mark, I've been getting up to speed on JMeter. I've used > selenium before. "The particulars depend on your particular > application" - agreed. That part I can work out myself by looking > at bottlenecks, generally timing areas of the application with more > and more granularity, in places where the app behaves slowly. Just remember that you can't really benchmark your application with a single client. There are behaviors that only emerge under some kind of load. For instance, uncontended object monitors (i.e. synchronized methods, blocks, etc.) in the JVM can be obtained very quickly. So, if you have a resource that requires serialized access (e.g. db connection pool), it may perform very well under an isolated test: you find that your most time-consuming request/response pair takes, say, 850ms. That's great: you do the math and say that you can handle 1.18 req/sec on average and with users expected to make 1 request every 10 seconds, that means that you can handle ~12 simultaneous users with no apparent slow-down. Then you get contended locks, which are slower. Instead of roughly zero time to obtain an object lock, let's say it takes 50ms (that's grossly overstating the amount of time required to obtain an object lock, but somewhat instructive). So now you're up to 900ms for your transaction and you can handle 1.11 req/sec with no slowdown and you can only handle 11 simultaneous users. Multiply those effects by a lot (lots of transactions, lots of users, lots of multi-threaded conflicts) and you can find that you really can only handle 91% of the traffic you thought you could. If you use JMeter, your software will get better: you will be able to identify those transactions that don't perform well and focus your optimization efforts in those places, instead of just reading code, changing StringBuffer to StringBuilder and new Integer() to Integer.valueOf() and convincing yourself that you now have an optimized piece of software. With a load-testing suite, you can prove to yourself (and, perhaps more importantly, your boss) that your software can handle the load you expect. It also helps with resource planning: if you know that a single instance of Tomcat on X hardware can handle Y load and you expect Z actual load, then you know you need Z / Y pieces of X hardware to run properly. Then multiply by some fudge factor (say 20%) and take the ceiling of that (so you always have an extra server... just in case). So maybe it's more like [ Z * 1.2 / Y ]. Oh, and remember that Z needs to represent *peak load* and not average load. If you have an online flower shop, you need to plan for the week of Valentine's Day during business hours, not the following Saturday in the middle of the night. Gather a ton of data and look at it. Graph it. You will learn a lot. Oh, and if you're using httpd (you didn't say), you might want to look into the "event" MPM: it won't waste connections waiting around for KeepAlive requests that never come from clients. The default MPM for httpd 2.4 on *NIX is "event" when supported by the OS and prefork for httpd 2.2. I believe "event" is stable on 2.2 -- just not the default. Benchmark with and without it and see if it makes a difference. With JMeter, your tests might be distorted because of how the tests run (e.g. constantly). You might have to fiddle with the JMeter configuration to get it to act more like a "real" browser by leaving connections open for a few seconds after making all the requests for a page. Then you may notice a difference. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJR/HgrAAoJEBzwKT+lPKRYkR8P/R5W8g/vnfEH/QxFfsQMCJnT TDv4oZecfNZ2PDZjGj+KpAJv6OoDe9wQLlAR4VWZMmnI3qJPqVwWg04ZSnEszf22 XkiuvnbPQXwt95bTXk/zPp5lcb4kuLAwvokAyMQQo7P941SYOmvA+xEADmlE8Vfc AgxnQY7GnifBU1wLZtzXrDnUWOzYwEL2vsec1bmlasbBg5NpxsQ9IyAq3DcPmDtO hQUbET12JTjka51Ub6TG5gP2O+ZzYz50XyVtUWcn86u4acZYmvfCtFq/XilZXv4G 962bNxXinf9GmoeCokCOejJ/Ob8XC7UpXtTXTJlzx64Gn8EDNKYyZxg6wt6MLktq xppytGQ+FfsxEFRtn9a0UM5Am0+7L4OpQWXesm5IcdypGNWn9Ng4bg2YI3c+P//O Q0eyS7WN19oFMvq60tbKHfhCv7QFYQatKnxiAChDsFoA53u6xZIlzmz5h/0G2kCH h7u57zUh2sSiBkSEs7QOxYNHS2tfTAAO2d5CMTuiAnIYk0joo0gOZ7u50DpAXaoR lnxcimpO+wy5Qc3AEfZtYlmco+EhjJ4hHZyCvcE3MRkGdrWODHZkV1+B9TB0TH3M sp1MEr3dlKeMDTj9jwB7mny8BY8lmIsPjWLl1s0wW+IST4Z4ax2t5eDvFDwtgtHy t9b2VNjEizaTBrp88r7T =iVJy -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
