Sadly, I don't think so, but what a great idea for a tool someone should write. You should make a bugzilla enhancement request for that.
-Mike On Wed, 2005-08-03 at 16:02 -0400, Jon Andersen wrote: > Peter, > > It appears that Sun SSL -:> OutOfMemoryException is the culprit. I ran > the same script without SSL, and don't see the memory usage growing. > > Is there some way to switch from the default "HTTP Request" > implementation to the "HTTP Request HttpClient" implementation without > rewriting the script? Do both use the same configuration, so I could > do a search-n-replace? > > Thanks a bunch! > > -Jon Andersen > Software developer > 734-260-6083 (work) > 734-646-5577 (home) > Digital Media Commons - Duderstadt Center > University of Michigan > > On Aug 3, 2005, at 3:14 PM, Peter Lin wrote: > > > I've run optimizeIt on Jmeter about 3 dozen times when I wrote the > > various samplers like Webservice, jms, accesslog and tomcat monitor. > > Under normal conditions, JMeter's memory usage is constant. I've run > > tests using OptimizeIt on JMeter for 500K, 1million and 2 million > > requests. > > > > what I haven't done is try it on SSL. I believe there's a known bug > > with Sun's SSL implementation which results in connections not closing > > and resulting in OutOfMemoryException. The solution to that is to use > > HttpClient sampler instead of the default one. > > > > the default http sampler uses the Sun implementation, which I believe > > exhibits that behavior. the HttpClient version should perform better. > > You can also verify this by using HTTP with the same test instead of > > HTTPS. If the bug doesn't appear in non-secure HTTP, it would support > > the idea that HTTPS is the cause. > > > > I know that some EJB containers use Sun implementation for SSL/HTTPS > > and they exhibit the same exact bug. If those connections are > > time_wait and aren't getting cleaned up, it's very likely the known > > SSL bug. > > > > peter > > > > > > > > On 8/3/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Hi, > >> > >> I've created a script which generates thousands of HTTP requests; the > >> script seems to work fine, but I'm seeing a large memory leak in > >> JMeter > >> itself. Before you write this off as a "newbie" question, here is > >> everything I've tried to do to fix it: > >> > >> 1. Deleting _all_ listeners. I still see the memory leak, even when > >> running without any listeners. > >> 2. Stopping the test and doing "Clear all". The memory is _not_ > >> reclaimed, even after a full garbage collection. > >> 3. Increasing the memory available to JMeter to 1GB. As the test > >> runs, > >> the memory usage climbs until its doing continuous full garbage > >> collections. Eventually an OutOfMemory exception occurs. > >> 4. Switching the HTML parser from the default to the > >> RegexpHTMLParser. > >> Still see the same memory leak, albeit slower. > >> > >> Does this sound familiar to anyone? It appears to be a slow leak > >> per-request. I'm running XP against an SSL-enabled server. Does SSL > >> leak > >> memory per-connection? "netstat -n" shows thousands of connections - > >> and > >> it looks like they don't go away until JMeter quits. > >> > >> I only see the leak if I do on the order of 100,000+ HTTP requests. > >> I can > >> send interested parties the script to test for themselves. I'm not > >> attaching the script now since its 500KB. > >> > >> I really need to figure out what is going wrong. I'm about to > >> attempt to > >> run a memory profiler (OptimizeIt) on JMeter to determine where the > >> leak is > >> under-the-covers... > >> > >> Thanks, > >> > >> -Jon Andersen > >> The Sakai Project > >> http://www.sakaiproject.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
