I recently finished writing a custom plugin in Kong 2.0.3 using golang to proxy API calls to correct upstream instance depending on various conditions like request path. It also decodes JWT and based on the parsed information decides which underlying upstream instance to route to. We have a heroku stack and I have upgraded kong heroku build pack to use Kong 2.0.3 (https://github.com/heroku/heroku-buildpack-kong/pull/25) so we can run on heroku.
While in development it works OK I am worried about production usage using golang especially because of the fact that it’s an out of process plug-in and uses MessagePack RPC as a bridge to communicate. Can the go pluginserver handle production grade loads ?Anyone who has been using go plugins in production who can share his experience will be of great help.
+1 on this question!
Digging through the source code and realizing how it all worked, i formed this question as well. If you make a bunch of requests for headers, or any of the request context, it could end up being quite taxing to poor little nginx
Curious if anyone in the community has run any kind of testing/benchmarks.
I think its best to load test and confirm your use case personally, no other better indicator than your own personal environments. All I can find on some testing in git issues is here:
So there seemingly is a performance hit, at least for some users, from this isolated test case sample. My personal tendency as a community member is right now “can I do it pretty easily in lua?” If yes then I stick to native lua plugin. If I hit something really challenging that a go dependency could help me a bunch on it then I will look in the go direction.
I am worried about production usage using golang especially because of the fact that it’s an out of process plug-in and uses MessagePack RPC as a bridge to communicate. Can the go pluginserver handle production grade loads ?
That does incur in some overhead, so they won’t be as fast as native Lua plugins, but in our internal testing the in-process and out-of-process versions did not cause significant performance difference, and the out-of-process version had better compatibility with different environments: the pluginserver can be compiled separately from Kong so it’s much easier to switch Go versions, and musl libc (used in Alpine containers) has trouble with the dynamic linking that happens with Go runtimes running on forked processes. So that’s why we went with out-of-process.
From the Kong development side, we have seen people observed that the plugin performance depends mostly on the number of PDK calls.
Anyone who has been using go plugins in production who can share his experience will be of great help.
Looking forward to hear about people’s experiences on this!
Our telemetry data indicates that there’s definitely people using Go plugins out there with Kong, but as Jeremy said, suitability always depends on your workload. If you need the very last drop of Kong’s performance, you need to go to Lua plugins, but depending on what you’re doing, the flexibility of being able to develop your plugin in Go may weigh more — that’s why we’re making both options available!
