Doubt in rate and workers

[bmpandrade]

One of the doubts I have is the workers flag. For example, I have a rate of 1000 req/s and 1 worker... this mean I'll have one thread sending the 1000 requests?
What about 10 workers? Means that I have 10 threads sending 1000 requests in total right? Not each one.

Is possible to configure Vegeta to have 10 workers sending 1000 req/s each? Not in total.

[tsenart]

Most of the time, you shouldn't have to care about the -workers flag. It was added to limit the amount of concurrent go routines (green threads) used in long load tests. By default Vegeta spawns one go routine per request and that works very well for most input parameters.

[bmpandrade]

So, if I define 5 workers, they'll be spawned in total or as vegeta need them?

[tsenart]

They will usually be spawned faster than they'll be used. What's your issue / use-case?

[bmpandrade]

Basically I'm running some load tests agains ElasticSearch and Apache Solr REST API.

I'm have some doubts about vegeta...
does the workers simulate clients or I need to run different instances of Vegeta with --workers=1 ?

[tsenart]

The central unit of Vegeta is the rate, not workers. Don't think about
workers for now. Think about how many requests per second you want to throw
at Elastic Search and Apache Solr Index. For instance, assuming you'd want
to try out 1000 req/s:

echo "GET http://..." | vegeta attack -duration=60s -rate=1000 | tee
results.bin | vegeta report

On Fri, Dec 19, 2014, 11:13 Bruno Andrade notifications@github.com wrote:

Basically I'm running some load tests agains ElasticSearch and Apache Solr
REST API.

I'm have some doubts about vegeta...
does the workers simulate clients or I need to run different instances of
Vegeta with --workers=1 ?

—
Reply to this email directly or view it on GitHub
#107 (comment).

[bmpandrade]

basically I did a shell script to execute a lot of attacks, sequential, with different duration, rates and workers. The, I analize them via plot reporter.

I just have doubts on the workers. If each spawned worker connects itself, as a client, to Elasticsearch. Doing parallel requests

[tsenart]

Each worker will issue requests against the targets. HTTP Keepalive is
enabled by default so the underlying TCP connection is reused when not
blocked on waiting for a response from a previous request.

On Fri, Dec 19, 2014, 11:47 Bruno Andrade notifications@github.com wrote:

basically I did a shell script to execute a lot of attacks, sequential,
with different duration, rates and workers. The, I analize them via plot
reporter.

I just have doubts on the workers. If each spawned worker connects itself,
as a client, to Elasticsearch. Doing parallel requests

—
Reply to this email directly or view it on GitHub
#107 (comment).

[bmpandrade]

If a disable HTTP Keepalive and define some workers, probably I can simulate multi-client benchmark environment, right?

[tsenart]

What is your understanding of a multi-client benchmark environment?

On Fri, Dec 19, 2014, 11:54 Bruno Andrade notifications@github.com wrote:

If a disable HTTP Keepalive and define some workers, probably I can
simulate multi-client benchmark environment, right?

—
Reply to this email directly or view it on GitHub
#107 (comment).

[bmpandrade]

Simulation of a real situation where different clients are in different machines. In my case I just want to ensure that "clients" don't share connections...

[tsenart]

Are the kind of clients you're referring to Web browsers? If so, most
modern web browsers use HTTP Keepalive by default, when the server supports
it.

On Fri, Dec 19, 2014, 12:00 Bruno Andrade notifications@github.com wrote:

Simulation of a real situation where different clients are in different
machines. In my case I just want to ensure that "clients" don't share
connections...

—
Reply to this email directly or view it on GitHub
#107 (comment).

[bmpandrade]

Im focused on benchmarking elasticsearch and solr for an ingestion rate and how does they react when I increase the number of clients.

Later, I'll have a fluentd or bash/python script in different machines sending data in a stable rate to one of them. That's the reason why I want to test the both of them in a high-load and multi-client environment.

[tsenart]

Vegeta isn't a traditional benchmarking tool. It's meant to answer "How
does my service behave at X req/s" rather than benchmarking something at
it's peak capacity. If you want benchmarking, I'd suggest you use
https://github.com/wg/wrk

On Fri, Dec 19, 2014, 12:10 Bruno Andrade notifications@github.com wrote:

Im focused on benchmarking elasticsearch and solr for an ingestion rate
and how does they react when I increase the number of clients.

Later, I'll have a fluentd or bash/python script in different machines
sending data in a stable rate to one of them. That's the reason why I want
to test the both of them in a high-load and multi-client environment.

—
Reply to this email directly or view it on GitHub
#107 (comment).

[bmpandrade]

Thanks,

I'll give it a look.