jmeter-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Wolfe <wolfebrian2...@gmail.com>
Subject Re: Contribute a Dockerfile for JMeter
Date Tue, 15 Oct 2019 15:12:00 GMT
After looking more closely at the proposed dockerfile that UBIK has
proposed. I have some observations.
It looks like its a simple container that just runs plain jmeter with a
test case file and logs data to a file.
>From what I can gather this is intended to be run with docker compose as a
container based process. So basically it is running a standalone jmeter
instance which generates load for your given test file.

I am not sure this is the best direction. As in order to scale up you would
have to combine the result files from running many docker processes. This
is where jmeter server is more useful. You could run this docker image to
connect to other jmeter-server instances and get your results, but that
just wraps your jmeter process into a docker container. I don't see much
benefit to this at the moment.

I think the most useful docker image would be to deploy many jmeter-server
instances in a kubernetes environment, have some way to connect 1 client to
them all, and then run your tests.


On Mon, Oct 14, 2019 at 11:13 AM Vladimir Sitnikov <
sitnikov.vladimir@gmail.com> wrote:

> >Is the JMeter project prepared to provide support for any Docker
> >images and configurations?
>
> I suggest we push experimental Docker images, then we decide what needs to
> be adjusted.
>
> In other words, we could start with "try JMeter" image that just launches
> JMeter.
> Of course, there will be corner cases here and there, however, we would
> just ignore the "backward compatibility" issues for Docker image,
> and we could stabilize it for a couple of releases.
>
> However, I agree we should at least try to enumerate the use cases for the
> image.
>
> Vladimir
>


-- 
Thanks,
Brian Wolfe
https://www.linkedin.com/in/brian-wolfe-3136425a/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message