воскресенье, 19 марта 2017 г., 21:15:25 UTC+3 пользователь Konstantin
Shaposhnikov написал:
>
>
>> As you can see, your hypothesis is not true, more then 99 percent of
>> requests is really fast and occur less the 1 millisecond! And I try to find
>> our what happens in this 1 percent!
>>
>>
воскресенье, 19 марта 2017 г., 20:46:16 UTC+3 пользователь Jesper Louis
Andersen написал:
>
> On Sun, Mar 19, 2017 at 4:58 PM Alexander Petrovsky > wrote:
>
>>
>>
> * The 99th percentile ignores the 40 slowest queries. What does the 99.9,
>>> 9.99, ... and max
https://github.com/valyala/fasthttp/blob/master/README.md FAQ says "net/http
handles more HTTP corner cases".
For me, that means not following the specs.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop
>
>
> As you can see, your hypothesis is not true, more then 99 percent of
> requests is really fast and occur less the 1 millisecond! And I try to find
> our what happens in this 1 percent!
>
>
I was probably not clear enough with my explanation. In 99% of cases
net/http (or fasthttp)
On Sun, Mar 19, 2017 at 4:58 PM Alexander Petrovsky
wrote:
* The 99th percentile ignores the 40 slowest queries. What does the 99.9,
9.99, ... and max percentiles look like?
I'v have no answer to this question. And I don't know how it can help me?
Usually, the maximum
As I know it's doesn't matter, before I've used net/http, and the situation
doesn't change, except the count of allocations, they are reduced
Could you point please where fasthttp doesn't follow the specs?
воскресенье, 19 марта 2017 г., 20:00:25 UTC+3 пользователь Tamás Gulácsi
написал:
>
> As
As fasthttp does not even follow the specs, you cannot assume that all requests
are parsed the same, till you prove it.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an
Hello, Jesper! Nice to see not only in erlang community!
воскресенье, 19 марта 2017 г., 18:09:17 UTC+3 пользователь Jesper Louis
Andersen написал:
>
> My approach is usually this:
>
> When a problem like this occurs, I very quickly switch from random
> guessing at what the problem can be into
Hello, Konstantin!
воскресенье, 19 марта 2017 г., 14:19:36 UTC+3 пользователь Konstantin
Shaposhnikov написал:
>
> Hi,
>
> External measurements probably show more acurate picture.
>
Of course!
>
> First of all internal latency numbers only include time spent doing actual
> work but don't
My approach is usually this:
When a problem like this occurs, I very quickly switch from random guessing
at what the problem can be into a mode where I try to verify the mental
model I have of the system. Your mental model is likely wrong, and thus it
is leading you astray in what the problem
Hello, Dave!
воскресенье, 19 марта 2017 г., 3:28:13 UTC+3 пользователь David
Collier-Brown написал:
>
> Are you seeing the average response time / latency of the cache from
> outside?
>
I don't calculate average, I'm using percentiles! Looks like the "cache"
don't affect at all, otherwise
Hi,
External measurements probably show more acurate picture.
First of all internal latency numbers only include time spent doing actual
work but don't include HTTP parsing (by net/http) and network overhead.
Secondly latency measured internally always looks better because it doesn't
include
Are you seeing the average response time / latency of the cache from
outside?
If so, you should see lots of really quick responeses, and a few ones as
slow as inside that average to what you're seeing.
--dave
On Saturday, March 18, 2017 at 3:52:21 PM UTC-4, Alexander Petrovsky wrote:
>
>
13 matches
Mail list logo