It matters to us because we are talking about response time of under 10ms for 500 concurrent users. Our internal application metrics are in the nano-seconds. If the container adds a lot of overhead, we may want to switch to other containers.
For scalability testing, our testing is done in a closed network. All machines are on same subnet, so we eliminate network being the bottleneck here. If anything, it will be either: client machine, server machine, app code, DB. No firewall or anything in between for initial test. Basically, I used JMeter to run 500 concurrent users against our app. The response time shown by JMeter is the total response time. total response time = network round trip + time spend on server network round trip = time spend sending request + time spend receiving response time spend on server = time spend running container code + time spend running app code + time spend talking to DB (include db round trip) Let's take an example using my results, JMeter reports that for 500 concurrent users making request to our application, the average response time was 1 second. That already broke our SLA which is 15 milliseconds. My questions that needs to be answered: 1) out of that 1 second, how much was due to network? 2) out of that 1 second, how much was spend running our application code? I got this, we have internal metrics 3) out of that 1 second, how much was spend running tomcat code? this maybe a bit off track to the initial question, but those are the things I"m trying to answer. I've been looking at tools like "Manage Engine" which shows you average response time which they claim is time spend in tomcat. However, they only show down to the millisecond level. And, if they're able to show that, it means that they're calling some tomcat APIs. I want to know which APIs, so that I can write my own program to query them. Christopher Schultz-2 wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Wicket, > > wicket0123 wrote: > | Hi Charles, > | Thanks for the reply. JMeter doesn't help me here because the > response > | time includes network time. The reason I'm looking into the tomcat API > is > | because i want a way to query tomcat for the numbers. So, the metrics > I am > | after are: > | > | 1) How much time was spend in tomcat? no network > > You can't get this information without a real profiler, which will, of > course, interfere with performance. > > | 2) How much time was spend on the servlet? > > The best you can do, here, is to write yourself a Filter (or Valve, I > suppose) and simply take timestamps. As with all instrumentation, taking > samples takes time. Rest assured that reading the system clock is /very/ > fast. ;) > > I suppose if you know the total response time and the servlet time, you > could simply subtract the servlet time to see how much Tomcat "overhead" > is in there. Does it really matter? > > | 3) What is the overall average response time for a request when there > are X > | number of users active? > > To me, this all comes down to /useful/ metrics. For instance: who cares > what the response time is on the server for a single request? Nobody, > that's who. This last metric is the only useful one you've requested, > and I would argue that you ought to do it over a network (even if it's a > local one). > > All users will be remote. Why artificially lower your response times > when everyone will have /at least/ the overhead of going over a local > network segment? > > Unfortunately, your choices are: > - - instrument your server and get inaccurate, but fine-grained data > - - instrument your client and get accurate, but somewhat coarser data > > Just my two and a half cents (US dollar really sucks these days), > - -chris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkfr4RMACgkQ9CaO5/Lv0PCYHQCfa+hDE77eSM476JmIqVpv2/ed > 3DgAoKQEvRO7KJOp3swJ21sMwjAcHOX7 > =2q9H > -----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-tp16319903p16341386.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]
