how to understand latencies.kong in log, it’s weird.
same http request with different response time. sometimes, latencies.kong is much more that latencies.proxy…why?
I think I saw your github issues post. You mentioned you had the TCP plugin enabled. Have you monitored how resilient your TCP sink is handling each API transaction(might be hanging in your transaction there on an overloaded server)? I recommend UDP as a fire and forget rather than TCP honestly unless you are insanely concerned about your metrics/etc being exactly 100% accurate rather than 95% 
.
Verify it by turning off TCP plugin see if the proxy call is that bad. My findings so far is Kong adds anywhere from 10ms to about 60ms max generally under load(metrics/auth/logging/custom-plugin/local rate limiting), which for an opensource free product is solid IMO. I am sure they would like to get that down to 1-10ms under duress in the coming years 
, and I hope they do too cause its a super cool application.
ok,i will try it. Thanks.
i have tried udp-log and delete tcp-log plugin, but no use.
other apis with low kong latency but one.
this api with below features:
- get data with body size 1MB-3MB
i have change body buffer from default size(4kb) to 2MB. but not use.
is there any relations between body size and kong latency?
thanks for answer.
Hey, so the more I think about it and discussed with kong dev the TCP/UDP plugin should not be impacting performance even if your TCP sink is slow due to nginx/openresty being async unless its so slow and you push such a high TPS you run out of worker threads to handle juggling the calls(someone correct me if I am off here). So knowing your payload is large has some impact, if you use any plugin that reads the request body and you go over the buffer size it will write to disk and make the tx slower due to file i/o. Have you verified how much available RAM you have on box and try setting the client body buffer to 4m, Nginx will only allocate what it needs anyways.