One could definitely imagine that the entire processing time for the test plan increases with Graph as a view. So, it is definitely time-consuming. The graph here is the response time graph where time is in millisecond against figures like data(black) which is actually sampler's requests, average( blue), median (purple), deviation(red), throughput(green). Now Throughput is important here, where throughput means the rate of processing a request here. This graph would become more and more crucial when we are trying to find the load a server can take up as when green lines suddenly go up, the time to process requests increases which means the server is not able to efficiently take up the load here.
Assertion results depict the response received from the sampler and compared with the assertion applied. You will see row-wise if the result has passed or not. Obviously, this would also consume a lot of space and memory. Assertions could be in space, size, duration. Below we applied assertion on the basis of size whether it is equal to 1000 bytes or not. Since our result failed, the output was as below.
View Results Tree:
View Results Tree is the most appropriate way of viewing a response from a sampler as one needs to know the Response code, Response message, data, etc just like you get in postman. Also, it is much faster than graphs and comparisons and gives a wholesome idea of the response get but, of course, you won't get a clear picture of if the response is slowing down till you traverse through the entire response.
Aggregate Reports show the similar data of the graph, but here in the table. More Columns here are added with min, max also the same throughput, average, median to again find the report of the actual result obtained against time. You will even find error% to give a better idea of the load resistance of the server.
View Results in Table:
View Results again take up a lot of memory and space. It has few fixed columns of latency, status, bytes where latency means the amount of delay caused. So, it is only suited to check if the cases passed or failed in one glance. The below figure would make it more clear.
Simple Data Writer:
Simple Data Writer is the most efficient way of using a listener as it only records the data to the file and not to the UI. Which saves a lot of time, memory and is quick. But of course one won't be able to visualize data at the first glance itself.
Aggregate Graph is an extension of the aggregate report with the same columns of min, max, average, median, throughput but the only difference here being that not only you can view a bar graph here but also save the graph as. PNG file format. Again formation of a graph takes a lot of time and space and should definitely be minimized.
Response Time Graph:
Response Time graph is a line graph for the response of the samples which gives the best understanding as to when the load capacity of the server was challenged. Time is in millisecond here. You can look at the below image for a better understanding of where the x-axis represents when the request was sent to the server and the y-axis the duration of response taken.
The beauty of Jmeter lies in the fact that not only you can send in the request to the application server, but also check the load on the mailing server. Here we are testing the Gmail server for firstname.lastname@example.org via providing login, SMTP, port, and password. Though Gmail restricts it due to the unauthorized testing application and you need to configure the security checks here.
It is one of the most advanced listeners available, where the result to be stored here in the file, is filtered using scripts and variables. Up till now, we had the option to choose the UI of choice, but here we could script the output stored in the file.
The summary report is similar to the aggregate report but the fact it uses less memory. It too records one row at a time. But aggregate reports 90% line and 95% line which is not there in the summary report as you see in the screenshot below.
Currently, all the results together are saved in the XML format. But save responses to a file allow to filter only successful or failed to store in the file which improves the efficiency of the test plan and faster output saving both time and disk space as well.
JSR here means Java specifications requests to add further customization to saving response to a file via writing scripts. You can filter the response using variables and expressions. It is an advanced listener.
Here you are customizing the UI for summary where filter out the parts of response you want to visualize via adding scripts. Jmeter has allowed all the possible ways to generate the response.
Here you can compare the respective response of the sampler and their assertion values at the UI. It is mainly for the assertions and their results. Assertions are used to validate the response which could be based on size, duration, etc.
By default, graphite implementation exists. Backend listener is an asynchronous listener to implement BackendListenerClient. BackendListenerClient is an interface executed by the Jmeter which allows the client to do the cleanups using teardowntests.