3 ms·
Do you mean under performing as in proxying performance? We do know there are some code paths that need to be optimized. For 1.2 we will be working on those iss
by bungle 8y ago
Do you mean under performing as in proxying performance? We do know there are some code paths that need to be optimized. For 1.2 we will be working on those issues, and for many of them, we already have solutions (in many cases more than one approach). A warmed up Kong usually runs with sub-millisecond latency, the plugins can usually add more to it, but sure there are rough edges, especially in p99. We'll just need to pick up the best ideas that have already been proposed, either by us or our community. For some issues we have a public pull requests in place for discussion. And some of them we have developed in close collaboration with the community or customers. We sure want to be lean and fast. Especially now that Kong is used as a sidecar proxy in service mesh.
- gengstrand 8y agoThe load test would call kong which would proxy each request to the service being tested. Kong would be configured with the http-log plugin where performance data would get sent to another service that would collect that data then update elasticsearch in bulk. Last August, I tested the Dropwizard service with this setup which recorded about 20,000 RPM on GKE. This year, the same setup sent about 4,000 RPM to the Dropwizard service and the http-log plugin sent only about 200 RPM to the other service.
- bungle 8y agoUh, that is a deep drop. Just thinking, could it be related to this: https://github.com/Kong/kong/commit/de4a002565a1723bff9014cb268811b96688af6b#diff-42179ec4ac8902bb7c13b1999a071e5d https://github.com/Kong/kong/commit/de4a002565a1723bff9014cb... Definitely something for us to investigate! Thank you for feedback (I'll collect this information to our backlog).