Lots of time I apply best practices that I learn over time or are recommended by experts (Like Mark Thomas). You do that first as early in the development life cycle as possible. Funny I guess how these best practices come from developers, vendors (like Sun and now Oracle) and DBA's ect. If you can not get your performance to be the best with light load or expected load (actual users) then the tests you menton are a waste of time and too late in the solution life cycle. Some of us do not have million dollar test systems like HP Performance Center (which I use since I lead a performance Testing team) or open source tools that support JAX-WS. So being proactive where you can rather than later is my motto. My goal was simple and achieved and usage in production was what I mentioned (1-2msec) and a combination of using leading edge techniques combined with the old fashioned way of doing things. Best Regards, Tony Anecito JavaOne 2010 Dukes Award winner for Innovation JavaOne 2010 Future of Java Winner Currently #1 App Store Download for 3D Mapping and #2 for video app
--- On Sat, 7/21/12, David kerber <dcker...@verizon.net> wrote: From: David kerber <dcker...@verizon.net> Subject: Re: Location of Tomcat 7 jvm defualt settings... To: "Tomcat Users List" <users@tomcat.apache.org> Date: Saturday, July 21, 2012, 10:11 AM On 7/21/2012 11:09 AM, chris derham wrote: ... > 1. Create a automated test script to simulate some load > 2. You increase the load until the bring the webapp to its knees - > either>80% CPU or responses taking>1/2 sec to return > 3. Critical step - you tell your bosses the maximum level that the app > can currently support, e.g. X concurrent users performing A and B and C > routes through the app. > 4. If they say that's all they need, then stop > 5. Otherwise use a profiler to establish where the bottle neck is > 6. Fix it > 7. Repeat from step 2 > > Using this technique you make sure that you don't waste time fixing issues > that aren't really issues. As a programmer, its kind of hurts to admit it, > but programmers are wrong when thy guess where the performance issues are. > Always. This isn't my idea - read the performance tuning books. You'll just > make code more complicated, and less maintainable. I disagree here. Once in a great while (maybe 10% of the time), I think I know where my bottlenecks are going to be, and testing proves me right. Of course the other 90% of the time... D --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
