Sounds like you want an HttpSampler that throws away the bytes before saving it into the SampleResult. Making such a thing would be as simple as subclassing the current samplers and overriding the method that downloads the bytes. Instead of storing it in an adequately sized byte array, throw the bytes out and only return a byte array of the last 100 bytes or something.
-Mike On Wed, 2005-07-27 at 20:50 +0200, Sergei Riaguzov wrote: > On 7/27/05, Michael Stover <[EMAIL PROTECTED]> wrote: > > > > > It's been around for a while - I would say it's probably time to start > > > > using the HttpSampler2 in production settings. > > > But is it stable? What does it lack to stop being alpha version? > > > > It lacks someone making an executive decision to change the name. > That a very inspirational news. :) > > > > Do you think that changing it a little may improve memory usage? Maybe > > > it would make sense to remove all the links to this data as soon as > > > possible if there's no need in regular expressions checking and > > > listeners like that? > > throwing away data or never downloading it would surely save on memory, > > but that data is very often used > Yes, that's true - but maybe it won't be too hard to modify some > listeners and write MyHttpSampler2 or smth like that.. The idea is - > that mostly there is no need in such assertions as regular expression > checkings, some compilcated logics based on previos responds... > > >- either to check it against > > assertions, or to parse information from it for the next sample. > Acha, that's why the previous one is saved.. To make some decisions upon > it?... > > > Also, > > actually downloading every byte is an important part of the process, in > > terms of performance testing. > Yes, but I'm thinking about freeing all the links to this array of > bytes as soon as possible for garbage collector being able to free the > memory. > > > 1000 threads is probably beyond the reach > > of most client machines. > Well on P4 with 1.5 Gb of RAM and Linux with 2.6.8 kernel it appeared > to be possible. Someone tested it and afaik it worked. I think that > even more threads in JMeter are possible simultaniously if not that > memory usage issue... > > A simple Java application is able to generate about 5-7 thousands of > threads with Java 1.5 and this configuration. > > PS Maybe you can give some advices how to improve JMeters behaviour in > thousands of threads working alltogether situation? > > PPS Thank you for your answers! > > --------------------------------------------------------------------- > 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]
