Kong User Calls, 14 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: [User Call] Kong Gateway 2.5 | Performance Testing Framework

Description

Since the general availability of the Kong Gateway (OSS) in version 2.5 we feature a new Performance Testing Framework. In this session, we’ll showcase an example test used for Gateway development, detail how a Kong Developer can get an environment set up to use the framework, and walk-through extending the framework to match your testing needs.

Kong’s User Calls are a place to learn about technologies within the Kong open source ecosystem. This interactive forum will give you the chance to ask our engineers questions and get ramped up on information relevant to your Kong journey.

A

We're going to go ahead and get started. Thank you to everyone for joining us today. I'm michael heap, I'm the director of developer relations here at kong and I'd like to welcome you to today's online meetup, where we're going to be talking about the new performance testing framework from the kong gateway, 2.4 release.

A

Now for those of you that are new here, we take the first part of the meeting to walk through a short presentation and a demo uh paul will be doing the presentation and one trunk will be doing demo and then we're going to open it up for a q, a and discussion and at that point you'll be able to unmute and turn on your video.

A

But if anything comes up, whilst you're watching feel free to drop the questions in the chat tab at the bottom of your screen, we'll make sure we get to those uh when we get to the q a section of the call with that, I'm going to hand it over to paul to kick us off.

B

Thanks, michael so hello, everyone and uh welcome again just wanted to say uh thanks for taking the time out of your busy schedules today to be with us here on the community call. We really appreciate you being here. My name is paul fisher and I serve as the product manager for the kong gateway and joining me today is uh for a technical walkthrough is wang chung, an engineer on our gateway team as well, so with that, let's just jump right into it um onto the performance testing framework.

B

So I want to make this a little bit interactive to start we'll see how successful it is, but maybe by show of zoom hands- and I believe, there's a button at the bottom of your bar. To raise your hand, I want to kind of just pull the audience to see how many of you engaged in some type of capacity planning, maybe to help you understand how many kong nodes are required, for maybe a migration you're doing internally or if you're gathering some type of infrared information around concurrency.

B

So what happens if I have like x amount of users trying to make x amount of calls per? Second, at what point does uh sort of the gateway or your api start to break down.

B

um So if you click, maybe the thumbs up or the raise hand button I'm just kind of looking through the audience here. If you've run into these type of uh scenarios, I got some hearts. I got some hand raises.

B

Thanks for that, thanks that little survey, so in uh version two five of our gateway we've been incubating a new performance testing framework which we're excited to show you today.

B

um It provides an efficient way of carrying out uh performance benchmarks on the kong gateway, so on our side of the house in the kong gateway, github repository we've integrated this performance testing framework with github actions to help us from a maintenance perspective understand how performance changes all the way down to the pr level and you'll see here on the slide, a sample output from our own internal tests.

B

So with every pr we can trigger this performance testing framework to show the latency or requests per second, all the way down to the pr- and this is a really powerful tool for us internally, because maintaining the the open source gateway requires. You know a constant trade-off between performance and delivering really rich feature sets.

B

So with this performance testing framework in place, our engineering team has had the ability to start to plot this performance trends over time and so that we're ensuring that our gateway has a high performance benchmark. That's come to be expected by our community, and this is maintained with sort of every commit.

B

So what it means for you is, you know if you're evaluating how to build the proper environment for the gateway to say, match your deployment requirements.

B

Our goal with this performance testing framework is to help you better understand that and to collect metrics and data.

B

To help you more accurately estimate the hardware requirements that you might have and ultimately save you on costs.

B

Or if, for example, you'd like to understand how a particular configuration of the com gateway operates, say with a plug-in in a specific environment, this framework could be used as an accurate measurement of sort of gateway latencies, and that's something that we wanted to show you today in our sort of technical walkthrough.

B

So, in this session, we'd like to show you how to get set up with this performance framework, get an environment running we're going to showcase our out of the box tests that we use internally and, at the end of this session, we'll have a q a on benchmarking in general and I'd love to take this opportunity to kind of understand where your benchmarking needs are best served today.

B

This performance testing framework has a test that we built out of the box to kind of um use internally, so so we're continuing to evolve this framework and think about benchmarks and tests that may serve a broad range of our user group as we look to evolve this framework. So I also want to mention that uh all the resources that we'll show today, we will append to our existing doc article on our performance testing framework. So you can kind of get it set up and running quickly and help provide feedback.

B

C

That I'd like to.

B

Kind of turn it over to longchang for more of a technical walkthrough of this.

D

Cool uh hi, everyone stop sharing yeah uh yeah. My name is, and I work with a cartoon, and today I would like to share a session with all of you to like uh actually gets on. I get hands-on to use that performance testing framework and as we're trying to be like more flexible uh for for just to get on these uh tools as fast as we can, and we are choosing the docker approach here. uh Let me actually share my screen first.

D

So if you have your laptop uh around, you can uh just follow my command and work at this um pretty soon like just a few comments, and so we'll be using the docker uh image on black image and since we are using the darker approach here, so we're also going to mount the docker socket into the container and actually understand this come on zoom chat, so we can just click paste.

D

Okay, so also we're also running using the in the root user, since we need to access this docker socket and you don't need to want. You don't want to use that on your production, because um in this image you are using, nobody is supposed to be more secure.

D

Then, when you put okay so since I already have this image locally and then I'm already in this container and the version we're using here is 2.5, and since this is a image, you'll be running through production traffic and we do not have other like development dependencies inside this container.

D

So the next thing we're going to do is to install several dependencies for development uh I'll, be installing the darker ci and also some headers or headers, and the compilers to make the the test we're going to run happy. uh So it takes a few seconds.

D

uh I see where this is running. I can also describe next step next next step, uh so in car uh we are using a tool. We call basket.

D

It is like a lower testing framework and we're using it for unit tests and also into end-to-end tests inside the calm and the the performance testing. Work is also based on the basket so for next step. We're actually going to install the uh the basket framework in our container because, as I just described, this is like development dependency and it's not included in the coin. Shipped.

D

D

Let's install this.

D

All right, this is like lighter than the headers we saw earlier, and then we're actually going to run this because we have all the dependencies ready- and uh I have this like a template um test- I'm not having the camera, but in a separate branch.

D

So we're going to clone this camera apple, which included all the test pictures we do not, including our image, uh we're using the this. This branch I created for this meetup and it included some of the fixes we have and also.

C

There's a sample.

D

Test that you need to go through later.

D

And, unlike the the files you see in this container- and this also includes a lot of like scenes for development like the box pack and uh like the written files and also this this stuff and this stuff- and those are those- are the spec and t the software testing and just like, without including your you know, image so into for this, for our uh repository and and the command you want to run for this. uh Anybody basic testing is is by using uh the binary.

D

We have on the beam, uh investing and then the fire you draw for and, for example, uh a car we use having a new test, and example uh the rock spec spec testing and yeah. So this is like what you expect from running a test, but this is for just a general 10 unit test and start for the steps, um but it will be very similar and if you change used to be 0 4, which is the curve, include all the percentage things in the stream meetup.

D

We have new tests that we can just see the results and I keep responding for a while and this one I go to another one. I'm gonna show you the the firing side: okay, zero, four.

D

So for every test, you're running here, it's actually a raw file and just like the extension name and suggested, and uh so we're going to set up this program setting framework like the environment uh because it's testing, so you expect a lot of levels to feedback and then, of course, we use the buckle driver here.

D

uh We can describe like the terms of driver later, but let's just use this injector now and um for every like uh test segment uh in basket, and you have this disquiet function to describe a like a block uh like it just for each actually just encoder and to include other like space and uh steps you want to set up.

D

uh You have this description here and this busy setup is another function. uh A car to set up the setup call actually so you'll get this uh hyper speaker to manipulate the quantities uh if we return by the setup and then you set up some service and routes. uh So the test we are testing here uh is to have uh two separate routes. um Point to the same service uh with your service is something really was set up for you in the framework uh it's just njx and upstream.

D

So it's the the performance options should be the bottom neck of your framework. um Then we're also going to have a plugin called creationid. uh It's just a simple plugin that has certain headers in response, and this won't be attached to this row. Two it will be attached to rot1, so we can compare.

D

The different stock performance is always out of working, and so here so see the results here, and uh um so this is like just a different part. Just for that and.

A

D

Each section of uh tests uh you'll see the results coming out and using the using the tool called wrk um to show you the request, ips and like requests per second and also the latency.

D

So this is without plugging, and this is grease and you can see there's a slightly difference. So actually the difference would not be that much because the running side, docker and the I'm kind of running zoom here so my computer is uh overloaded, so um yeah, let's go back so and you can get the basic idea here. That is that, and you have a slightly performance difference with this correction, id and plugin enabled- and this is just a basic uh idea. So let's go back to this test.

D

um This is just for starting call and stop calling down so five tests. We just copy paste about its parts, and this is a section. uh It actually makes a difference where you see the results, so it is actually just another description block and uh in this set in this block you can just start a load with five with five spreads and 1000 connections and last for 30 seconds, and it will hit this road one.

D

We don't have this plugin and then get results and get a result and in the next section, we'll moving into row 2, but we will actually have this plugin and it's also the same thing that you wait for result and print it out. uh Yeah. That's that's the basic idea. So, although this is very simple, it's very a simplified uh test, and just more than this, you can do and it's good.

D

uh For example, you can test between different versions. Let's see here, because when you start calling, you can actually point a version uh it can actually it can either be a github tag or a dock image or anything. You want to distinguish between different versions, and so you can actually test between your like different, maybe different, custom images or different companies. You made to compare um then also for the actual capacity planning.

D

uh You don't want to use um docker driver here, because docker is all running on your local machine and it will be very like flaky, based on the workload you're having on your on your laptop, so we also kind of provide some other drivers. um We provide a local driver where you don't want to run inside docker, so you can get some, maybe some network uh like a performance boost and without using the bridge uh network and also another java called terrible. uh This is the maybe the you know.

D

This is a driver. You will think for uh classy planning, uh so this will just uh invoke the telephone. We call it from hashicorp and it will spin up uh discovery infrastructure uh like a real pc2 instance or like a bare metal instance, or a google cloud instance, and it will actually run call inside and test and ips and agency, based on the the spec select and to strap because of the flexibility here. You can also add as many infrastructure details here.

D

uh You want to have a yearb and having your asg in your ec, for instance, and that's all for support- you just buy this much yeah. I guess that's it, and people have sure the talks were like describing the difference between drivers and how you want to select um yeah.

A

Yeah that was really interesting. um I've been copying and pasting all the things from the the chat that you shared, and I think my my project this evening is going to be building the docker image with all of that pre-installed.

A

So it's just a docker compose up for anyone that wants to go and keep the tires and try this out.

D

Yeah, definitely that's like actually exactly what we plan to do in the future and we're going to like uh maybe provide dr capra's fire or just like an image based only every release of call. So it's a like just for developing purpose. It's not for running content. You can use the image to run any uh performance tests or even the real normal, like end-to-end test details.

A

Oh, isn't that the the beauty of open source right? You have that on your list and thinking I I want to go and try this out, so I'm going to build it. I can share it and everyone here and everyone in the community can benefit from that.

A

C

I'm excited to try.

A

It so thanks for showing us, um we've actually got some time for questions now and if anyone's got any they'd like to ask, feel free to mute and ask, or you can drop them in the chat, and I will read them out for you.

A

No questions wong chung did such a good job explaining the performance testing framework there. We are, what is the minimum version of congo ss, from which the performance testing framework is supported.

D

uh Yeah, that's actually a good question. So um so actually that's like two different uh uh way of uh talking about versions, and so, as you can see here, we're running, uh I'm not sure but yeah. So we were cloning, the converter and also uh specified version around the test. um So when you clone the version, uh you have to use the chrome branch newer than 2.5, but that doesn't mean doesn't mean you can only test the coin newer than 2.5.

D

You can actually test any version even before 2.5, so the two only exists in the 2.5 branch and also a master branch.

D

But once you get the tools on you and you can actually use that to test any bridge yeah even earlier but yeah, I don't. I don't see you guys, like lowest minimum version of call. You can test if you find one they can, but I think it's like.

A

Excellent and I learned something then I thought it was only 2.5 onwards. Yeah, it turns out. You can test all the versions as well. It's just that the tooling golem comes from 2.5 onwards,.

A

Any other questions.

B

One thing I'm interested in learning too from everybody is uh we have this example? You know latency uh request per second test as a part of our meetup prep, but uh I'm kind of curious to learn what other kind of benchmarks are most impactful to the audience here in solving their challenges. You know internally, whether it be costing or concurrency or any kind of information around benchmarking. That's going to most help you uh we could potentially build some out of the box test for it.

A

One that I've been quite interested in is actually the number of consumers. So what is the the performance when I've got one consumer, 10 consumers, a thousand consumers like? Does it start to drop off at any point?

A

So if I want to map my my users to consumers like what's the performance impact of that, so that's why I'm thinking about building out.

D

Yeah, that's a good point and also like uh from front of the other side. You also want to know like the number of routes and service and yeah also.

D

Like upstream number, uh with regard to the performance.

A

So is there anything that anyone on the call um would like to test whether you do it yourself, whether it's an idea for us to pick up and write the the implementation for you like? What? What would you like to measure the performance of we've got roots services?

A

Consumers like what's on your mind when you're trying to scale.

C

Hi guys so generally well, while we run some performance tests at dream, 11, what we check is uh the latency that a plug-in that we have written introduces.

C

So that is one thing that we check very closely and it generally, what happens is when you start writing your own plugins and, as as the layers of plugin, keep adding on the latency increases, but we always keep a check that what is the trade-off and how much is the latency increasing, uh but I think this is already there in this performance testing framework.

C

uh That is something we can already measure so yeah. That is one thing that we generally check.

A

Thanks for the insight um interesting that it's primarily plugins that you write yourself yeah and there's a message from shivag as well about mostly the plugin overheads, can you tell us more about that? Are those in-house plugins or are you evaluating the ones that kong and the community provide.

C

Mostly the in-house plugins, as I not mentioned, we actually work at the same company, same team, so yeah.

A

That would explain why you gave the same answer at least you're aligned.

A

Now we have another question: can this framework be used for kong on kubernetes.

D

Yeah, that's a good case, and actually I've been asked by this question for our colleague as well, so um so the first challenge is no for now, but this is like something we are planning to do because with terrific, you have the complex provider and you can just bring up the compost and also like the workloads inside of the kubernetes cluster and from the up level.

D

uh You just see this as a con service and the service, and it will help you just transparent into the framework and it will just depending on how do you implement using the telephone driver and it can be yeah. You can also like spin up this workload on like a ecs. Maybe something like that hosted the next solution, and also maybe also on your local mini.

A

So if I heard that correctly like, we can't use it for kong on kubernetes as a performance testing target, but am I understanding it quickly that if we run the the performance test, I say locally or in docker or on ec2 like we might not get exactly the same requests per second, but the story should be very similar like if the requests take 20 longer with a plug-in.

A

Is that roughly 20 longer if we deployed to kubernetes as a runtime as well, or is that not really how it works?.

D

uh Yeah that doesn't, and also actually uh you can also spin up uh using using the telephone driver, um but not the like the docker driver, which we are demoing today uh with that scene. You can actually run the call inside of kubernetes and see what it performs uh with regard of your infrastructure setup, and so, but it's so. This is not like a support right now, but it's very easy to implement and both on our side of the community side.

A

Got it if someone wants to to take a stab at implementing that like, if you want to to try it out, I'm sure we'd be able to get the engineering help to work with you on the the pull request likes everyone's going to benefit from that.

A

Any other thoughts or questions.

A

A

A

All right, in which case we're going to wrap it up. Thank you for joining us today. Everyone uh thank you rangtron for the demo paul for the presentation. Just want to remind you all that our next call is on september, the 14th, and we hope to see you. There have a great day morning afternoon or evening. Everyone cheers.