Hi Philippe, Thanks for your time on analyzing the heap dump. It is unfortunate to hear that there will be no support of my test case from Jmeter. I suppose I could try to write my own plugin targeted on the performance for my test case. Is there any chance you could give me advice on which part of the code I should look into, in order to keep the memory utilization at a low level for my test?
Thanks and much appreciated. Jacky On Thu, Oct 11, 2012 at 8:07 AM, Philippe Mouawad <[email protected]> wrote: > Hello, > I looked at your heap dump, it seems you are load testing lots of > differents WEBSITES (I mean HOSTs are all different). > This is clearly a very "weird" use case that we don't handle for now, and I > am not sure we will. > > Regards > Philippe > > > On Thu, Oct 11, 2012 at 12:10 AM, unjc email <[email protected]> wrote: > >> I have uploaded the heap dump file online and it's available at >> http://dl.free.fr/qZBPvLRB8. >> >> >> >> Thanks, >> Jacky >> >> On Wed, Oct 10, 2012 at 3:20 PM, Philippe Mouawad >> <[email protected]> wrote: >> > Hello, >> > Which map are you talking about in HTTPHC4Impl ? >> > >> > If it's this one: >> > >> > - Map<HttpClientKey, HttpClient> map = HTTPCLIENTS.get(); >> > >> > Then it only exists once per thread and per combination of : >> > >> > - url.getProtocol()+"://"+url.getAuthority(); >> > this.hasProxy = b; >> > this.proxyHost = proxyHost; >> > this.proxyPort = proxyPort; >> > this.proxyUser = proxyUser; >> > this.proxyPass = proxyPass; >> > >> > so unless you change these per url , it won't grow a lot. >> > >> > Check what Deepak is suggesting and if issue persists, then generate a >> Heap >> > Dump and put it somewhere where we can download it. >> > >> > Regards >> > Philippe >> > >> > On Wed, Oct 10, 2012 at 8:53 PM, Deepak Shetty <[email protected]> >> wrote: >> > >> >> Hi >> >> its more likely that you have some listener turned on (like view results >> >> tree) - Even if a URL is 2000 characters you can calculate how many URLs >> >> before you use up say 100MB of memory. Do you really have that many URLs >> >> even if they are dynamic? >> >> http://jmeter.apache.org/usermanual/best-practices.html#lean_mean >> >> >> >> regards >> >> deepak >> >> >> >> On Wed, Oct 10, 2012 at 9:21 AM, unjc email <[email protected]> >> wrote: >> >> >> >> > Hi all, >> >> > >> >> > I have memory and cpu issues when running heavy load testing with >> >> > HTTP(S) sampler. The purpose of my test is to hammer the server as >> >> > fast as Jmeter can, using a big list of hostnames and URIs, via a >> >> > proxy server. The test plan I have setup is configured with >> >> > 100-thread thread group that contains a HTTPS Request sampler (using >> >> > HTTPClient4) and Summary Results generator. >> >> > >> >> > The machine I am using has 12GB memory and 16-core cpu. I monitor the >> >> > top output throughout the test. I notice the RES size of the jmeter >> >> > java process is growing really fast - it reaches 2GB heap size limit >> >> > in less 5 minutes. The test could never go beyond 30-minute mark >> >> > without OutOfMemory exception. I know there are plenty of free memory >> >> > for me to expand the heap size; but my concern is whether there is a >> >> > memory leak in the code. I worry the process would suck up all >> >> > available memory anyway if I run a stress test for a day or longer. >> >> > >> >> > I have skimmed through the code of HTTPHC4Impl and found that there is >> >> > cache "map" for HttpClient with regard to URL. I suspect this cache >> >> > map could go pretty crazy in tests that deal with large number of (or >> >> > dynamic) URLs. Just curiosity, I tried running a test with using a >> >> > custom sampler as like HTTPHC4Impl but without the cache map; it seems >> >> > help slowing down the pace of the heap size. However, the heap size >> >> > (RES size in top output) never seem settle at one level over time. >> >> > >> >> > Does anyone have any experience in running similar test as I do? Does >> >> > it look like a potential "memory leak" to you? Any comment or advice >> >> > will be appreciated. >> >> > >> >> > >> >> > >> >> > >> >> > Thanks, >> >> > Jacky >> >> > >> >> > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: [email protected] >> >> > For additional commands, e-mail: [email protected] >> >> > >> >> > >> >> >> > >> > >> > >> > -- >> > Cordialement. >> > Philippe Mouawad. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > Cordialement. > Philippe Mouawad. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
