On 14 May 2015 at 17:09, Felix Schumacher <[email protected]> wrote: > > > Am 14. Mai 2015 14:14:51 MESZ, schrieb Philippe Mouawad > <[email protected]>: >>Ok , let's forget about it . >>Thanks for feedback. > > What about compressing the output on the fly and thus using less space > instead?
That still won't guarantee to solve the problem, and will result in extra processing for JMeter. > Felix > >> >>On Thu, May 14, 2015 at 2:29 AM, sebb <[email protected]> wrote: >> >>> On 14 May 2015 at 00:10, Vladimir Sitnikov >><[email protected]> >>> wrote: >>> >> yes but isn't it then a result of the load test to know that your >>db >>> > tablespaces sizing or cleanup/archiving was not correct ? >>> > >>> > True. The problem is humans are prone to errors, so you'll run into >>> > that "not correct" issues eventually. >>> > >>> > Well, precondition check is a common need. >>> > I am not sure if it should/could be addressed by JMeter itself. >>> >>> I agree, this is out of scope for JMeter. >>> >>> I doubt it can easily be made foolproof, and if it does seem to work >>> people will rely on it and then blame us when some unexpected event >>> uses up the disk space. >>> I don't think it's worth expending any effort on it. >>> >>> Besides, if the system is so short of disk space that it can run out >>> during a test, it's probably already badly fragmented and will >>perform >>> badly. >>> >>> >>> > The volume required depends on the number of test iterations. >>> > Certain our tests include simultaneous execution of multiple JMeter >>> > scripts, so it is not that easy for each individual script to >>"foresee >>> > that there would be other scripts consuming the space". >>> > >>> > I think "out of space to write jmeter results" is rare issue for >>us. >>> > >>> > Vladimir >>> >
