If you have read my post Performance testing applications with a large response using JMeter, you already know the impact of having a test that retrieves a large volume of data from the server and also the way to reduce the impact by using MD5 hashing option in the HTTP Request Sampler.
But, what if you want to use a different sampler. Say for example, a custom Java Request sampler (or) the SSH SFTP sampler? How do you reduce the impact in these cases?
There are multiple ways to do this. In the case of a Java Request sampler, you can choose to code your own hashing algorithm to reduce the size of the response, just like the HTTP Request Sampler does. But, this might not always be possible/efficient. Example: SSH SFTP Sampler. In these cases, I think there is a very nice OS specific feature that could be used for our purpose.
Every operating system has a “sink” or “a black hole” location. Meaning, whatever you write to this “black hole” is lost forever (i.e.) not stored anywhere.
For Linux, this is at /dev/null
For Windows, this is at NUL
In cases like the SSH SFTP Sampler, I prefer to use this option. If you are downloading a file from a source server, then instead of writing this file to a local path in disk, you can write it to /dev/null (if you are using Linux OS)* or NUL (if you are using Windows OS). This will avoid the disk overhead and help you generate more load on the server than you would be able to do otherwise.
* These are not directory paths but rather file descriptors. So, your destination file name should be “/dev/null” and not “/dev/null/destinationFile.txt”.
Below image shows a sample SSH SFTP Sampler configuration that uses this option.