Also forgot to mention that setting maxKeepAliveRequests to -1 did not help. As expected from the connector documentation the default value for this attribute is 100 and we have a 60 user test set up.
On Wed, Nov 4, 2015 at 8:18 AM, dimple ranka <dimplekra...@gmail.com> wrote: > Hi Mark, > > Another observation to be noted here is that system CPU usage shoots up > for subsequent runs, especially for later runs. > > We have been looking into this issue for couple of weeks now and it is > clear in the same environment with the same setup it doesn't reproduce on > tomcat6. The moment we deploy the web application in a tomcat7 container > the slowness with subsequent runs shows up. > > Thanks, > Dimple > > On Tue, Nov 3, 2015 at 2:36 PM, dimple ranka <dimplekra...@gmail.com> > wrote: > >> Hi Mark, >> >> The test client is running on another machine. >> >> The server side test code is written using jersey 1.17. >> >> Will try out with playing with maxKeepAliveRequests. >> >> My only concern is that if jmeter is doing spoofy things then why it >> doesnt show up on tomcat6. >> >> Thanks, >> Dimple >> >> On Tue, Nov 3, 2015 at 2:27 PM, Mark Thomas <ma...@apache.org> wrote: >> >>> On 03/11/2015 06:17, dimple ranka wrote: >>> >>> <snip/> >>> >>> > ############################################## >>> > On tomcat7 number of requests fullfilled per second >>> > ############################################## >>> > * RUN1 ** ==> ** 38128.97704918033 runs/sec* >>> > *RUN2 ==> ** 19040.35947712418 runs/sec* >>> > *RUN3 ==> ** 19043.7908496732** runs/sec* >>> > * RUN4 ==> ** 19001.71568627451 runs/sec* >>> > ############################################## >>> >>> Every performance test I have ever done with Tomcat, the first run has >>> had poorer performance while the system warms up (threads started, >>> caches filled, session ID generators initialised etc.) and subsequent >>> tests have performed better. >>> >>> The results above suggest something about the test is broken. >>> >>> First of all, thank you for the detailed information. It helps a lot. >>> >>> Your server side test code won't run on Tomcat without additional >>> libraries and configuration that you haven't specified. That makes it >>> harder for people to reproduce your results. I'd recommend using a >>> simple servlet for testing in the first instance and only when any >>> issues have been resolved, move to your test. >>> >>> 20k requests/s is rather low. I'd expect those sorts of numbers from a >>> single threaded test on reasonable hardware. With 8*2 threads to play >>> with on the server I'd expect that number to be a lot higher. >>> >>> My experience of JMeter is that the results are unreliable as you >>> approach the point where the overhead per request for JMeter approaches >>> the overhead per request for Tomcat. You would probably get better >>> results if you switched to a lower overhead test client. I tend to use >>> ab for these sorts of tests. >>> >>> It is not clear from your original e-mail if the test client is running >>> on the same machine as the server or not. >>> If not, the network can have a significant impact. With this test a >>> gigabit network should be fine but we have seen network saturation in >>> performance tests for larger static files so do keep an eye on the >>> network utilisation just to be safe. >>> >>> The higher the throughput, the greater the impact of HTTP keep-alive. I >>> have frequently observed strange test results caused by the system >>> running out of free ports due to the churn rate of connections. netstat >>> is your friend. I'd recommend exploring the impact of different settings >>> for maxKeepAliveRequests. You almost certainly want something >>> significantly higher than the default of 100. A quick test would be to >>> set it to -1 and see what impact that has. >>> >>> HTH, >>> >>> Mark >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >>> >>> >> >
