Yup. DB will always be a bottleneck in any application, so we load balance it for optimum performance. So, we can "forget" the DB bottleneck since we add another DB if it starts hitting our threshold. So, the first test i did was to find out the DB performance and its maximum values. That is complete and I am moving on to fine tune the App server + Web server.
At the app. code level, we implement caching and loading stuffs to memory. For the purpose of finding the limits of the server, we disable caching. Our app. code will timeout after 500ms and return a default script to the client. So, there are many configurations that we can do at the app level and tomcat level such as setting the maxThreads for tomcat, configuring JVM options. I tried playing with all of them and I think I have found a reasonable configuration for our app. My observation shows that tomcat maxThreads affects performance speed of response time. This makes sense since more threads equals more CPU context-switching, and the threads compete for resource as well as waiting for each other for completion of tasks to access certain resources such as DB, etc. So, I looked at JMX Console and see that under RequestProcessor for Catalina it shows all the HTTP request processor threads. And, for each, it shows an attribute called "requestProcessingTime" which I think is the time it took to process that request. So, I was thinking to write a script to query that for each thread. Then, I thought there maybe something similar at the container level which will tell me overall request processing time for all threads instead of me querying all threads and making calculations. Christopher Schultz-2 wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Wicket, > > wicket0123 wrote: > | Since we cannot control anything that happens after a request leaves the > | server, we want every request to be processed within 25 millisecods. > The > | order of execution is very simple: > | > | 1. Client send ad request with some parameters, hits a servlet. > | 2. Ad server process the request which include app. code and talking to > DB > | 3. Ad server send response to client. the size of the response is > roughly 2 > | KB. > > If you're talking to a DB, this is likely to be the bulk of the time > spent on the server. I assert (with no proof ;) that Tomcat's impact on > your own code's response time is going to be a negligible percentage > (unless you are using SSL, in which case you are screwed). How fast is > your code already responding to these requests (without a servlet > container adding any overhead)? > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkftg3IACgkQ9CaO5/Lv0PB7aACgn43sMxldGO6BYWZ8m5S3XEFJ > 9ngAoLWm0g0K/z8A/8gJ1V+pOKMeO1Xh > =3KAk > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Checking-tomcat-metrics-in-a-non-intrusive-way-tp16319903p16398629.html Sent from the Tomcat - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
