On Mon, Jul 18, 2016 at 10:46 AM, Bakul Shah wrote:
> A number of nodes and machines and networks are involved in
> your test so you need to somehow further isolate the problem.
>
..
On Mon, 18 Jul 2016 06:03:26 PDT Rayland wrote:
>
> I have an HTTP server in AWS on an instance with 4 cores
On Mon, Jul 18, 2016, at 03:13 PM, Rayland wrote:
> Any thoughts on how to attack this problem?
You could run the tiny example that Peter Waller wrote with the same
test and share the results here. If we see the same slowdown pattern
then it would eliminate a problem in your code.
-- Ian
--
Y
A number of nodes and machines and networks are involved in
your test so you need to somehow further isolate the problem.
In place of the go http server, you can just put a simple
C/C++ based listener that accepts connections and closes them
right away -- that should measure raw connection accept r
Check also that you dont have any ulimits that are limiting the maximum
concurrent open files, each socket is a file handle, if you dont open it up
you can starve the vegita host of outbound connections. It may be worth
firing up 10 t1.micro instances and run 10th of the load from each.
On 18 Jul
The client and the server are two separate machines in aws. No middlewares
and proxies. I don't get any network related error.
On Jul 18, 2016 17:48, "Peter Waller" wrote:
> If you run it on the same server as the host, does it perform differently
> there? For example, did you rule out network s
If you run it on the same server as the host, does it perform differently
there? For example, did you rule out network saturation effects? Do you
have any HTTP middleware or proxies in the way?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To u
The command I used is: vegeta attack -targets=address.txt -body=request.txt
-duration=1s -rate=1000 > output.txt
On Monday, July 18, 2016 at 4:34:52 PM UTC+3, Peter Waller wrote:
>
> It really depends on what you're doing while handling your requests. It
> may or may not be reasonable. Are you t
Any thoughts on how to attack this problem?
On Monday, July 18, 2016 at 4:46:26 PM UTC+3, Michael Jones wrote:
>
> When you move the rate up by 5x, from 1k => 5k, your wait time moves up by
> 2846x. That is suspicious in any system, language, etc. ;-)
>
>
>
> *From: *> on behalf of Rayland <
>
I thought it was self explanatory, the handler does nothing, just returning
an error.
On Monday, July 18, 2016 at 4:34:52 PM UTC+3, Peter Waller wrote:
>
> It really depends on what you're doing while handling your requests. It
> may or may not be reasonable. Are you touching external resources
When you move the rate up by 5x, from 1k => 5k, your wait time moves up by
2846x. That is suspicious in any system, language, etc. ;-)
From: on behalf of Rayland
Date: Monday, July 18, 2016 at 6:03 AM
To: golang-nuts
Subject: [go-nuts] Understanding HTTP server latencies
5k req/s
Requ
It really depends on what you're doing while handling your requests. It may
or may not be reasonable. Are you touching external resources such as a
database?
Can you provide a minimal example to reproduce? It would also be useful if
you supplied the exact commands you are running.
I have managed
11 matches
Mail list logo
