Closed thiagoarrais closed 1 year ago
Hi @thiagoarrais, sorry for our late answer. First of all, thank you for creating the issue and be willing to contribute. We really appreciate that!
Regarding the issue, we would like to better understand your use case. Which backend do you mainly use? What is the scenario where the test data compression is necessary? What is your regular TestData file size?
As a maintainers we would like to avoid adding unnecessary complexity to the project without a strong use case. So far we didn't face testData issues internally with the backend other than JMeter.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
It's my turn for a late reply, @s-radyuk. Sorry for that. But here it goes:
My team uses mainly JMeter and K6 with Kangal. We consider K6 the most flexible of the two because of its ability to work with any testData file types. Stress test cases sometimes need input files larger than a megabyte and file types can vary a lot. Some applications need the usual CSV input, but we've also needed to use HTML, CSS and various image formats.
I do realize that a lot of those formats are already compressed (like images) and wouldn't benefit from another layer of compression and we can deflate the other ones before sending to kangal and inflate it back in the K6 test program. But that includes an additional layer of complexity for the test writer.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had any activity in the last 21 days. Feel free to re-open in case you would like to follow up.
I have noticed that the testData compression introduced by #177 is not implemented for some load generators (maybe it is only supported by the JMeter integration code). Does it make sense to extract this behaviour to Kangal itself instead of delegating to specific load generators/backends? Maybe the main engine could deflate the CSV before calling
backend.Sync
, for example. Conversely, there would need to be arranged some way to include the init container that the JMeter backend uses to inflate it back.Would the project be willing to accept a PR on that vein? This change could potentially include some other capabilities like the code that splits the testData CSV between workers, of course. Are there any caveats or potential roadblocks I should be aware of?