-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 John,
On 12/9/2010 5:15 PM, John Goodleaf wrote: > I agree [about benchmarking] and wish I had the time and resources to > do it. I need to deploy on very short timelines. There actually was a > performance testing phase budgeted, but it got killed after the > "business owner" dragged her feet on requirements early in the > project. Not that I'm bitter or anything... So... there was a benchmarking stage planned, but it's been bagged in favor of a consultant who simply tells you how to improve performance without any way to verify that the "improvements" are accomplishing anything? > The application in question is pretty damned fat. It's typical corporate > bloatware (it's an interface to Documentum). However, there are few > operations that are noticeably more memory intensive than others. Many parts > of the app actually rely on pushing an applet to the client. There are > several of these applets, each relatively small, and they account for about > 1 in 25 transactions based on my admittedly sketchy profiling. (User > operation profiling; I have not profiled the code.) Pushing an applet to a client should be roughly equivalent to the client downloading static content. Are you saying that those transactions are minimal (/only/ 1 in 25) or quite frequent? > There is a pool as you describe, and it will be a big, deep pool. The other > edge probably applies though. How many simultaneous requests do you expect to service at any one point? The connection pool only needs to be (roughly) that big. Also, you can't possibly use more db connections than the (sum of) maxActive setting(s) on your Connector(s) in a single Tomcat instance. How big are we talking? The good part about synchronization on something like a db connection pool is that only the borrow/return operations are synchronized... the duration of the borrow is not relevant to performance -- except that obviously connection unavailability for other requests might be an issue. If you have a big enough pool, though, then you shouldn't be worried about that. > The app is fairly stable. However, it requires IE 6 or 7 (don't blame me) > and insofar as I've seen stability problems, it has more to do with IE. In > other words, on the vast majority of hangs/freezes/whathaveyou, the server > logs show no problem at all. The catch is on the IE side. In any case, I > don't anticipate crashing JVMs. So, your clients crash but the server hums along? I guess if MSIE is the client platform, that's the best you can do :) (To be fair, MSIE 9 looks great... finally. It only took Microsoft 4 versions to get MSIE to be good again.) > I'll see what I can get him to cough up. My suspicion is that he's > repeating a formula arrived at long, long ago by a guy who doesn't work > there any longer. I have not observed him to possess any special skills in > the Apache/Tomcat arenas. If he tells you to change all your StringBuffers to StringBuilders then you know he's just wasting your time ;) > Thanks for your well written and thoughtful response. Can I hire you as a > consultant? If you're serious, contact me off-list if you need anything specific. I'm willing to give general advice for free on the list. ;) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0BkM8ACgkQ9CaO5/Lv0PDTSwCfe071+s3ijKMckFo+2qQXUYOL 7IoAn2aZ/48ujp42XbJ98UmIr1ZlssO3 =7dyR -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
