Load Testing a Django Application using LocustIO | Pranjal Jain & Vibhash Chandra

Speaker 1: Hello everyone, uh I'm Vibha Hasht. I work as senior developer at ServiceNow. Today we are going to talk about uh road testing Django applications using Lukas Taiwan. For this talk, I have been joined by my former colleague Pranjil Jil.

Speaker 2: Hey everyone, I am Pranjil. I work as a software development engineer at Amazon India. Okay, uh let me share my screen. Okay, so for this talk we assume that uh you have basic understanding of Django and Python. Okay. So I came to know about Locust Io when I was working on a web application sometime back At that time, our database update was failing in production under heavy user load. So we wanted to replicate this issue In our local dev

Speaker 2: environment, but uh we did not have uh load testing setup. So uh we were looking for something, uh some load load testing tool or uh library which could perform uh load testing very like which was uh very easy to set up up uh and did not require much perfectly uh load testing with uh locust io perfectly fits in this In locastyo, we can write Python scripts, run our uh run our tests, and get the results easily Okay. So one principle that I truly believe in is uh you cannot improve what you cannot measure.

Speaker 2: And load testing is a phase and software development cycle, which perfectly fits in this, which is very closely related to this principle. Okay. So um flow testing and uh stress uh stress testing come under the umbrella of uh performance testing In performance testing, we evaluate our system, our application, and get some metrics on speed and scalability of our system, response time of our application. Software and hardware resource usage. So in load testing, we check how much load our

Speaker 2: application can handle So the goal is not to find out any bug in our application or our system, but to eliminate the bottlenecks

Speaker 1: When we are testing our application for its functional requirements, uh in those cases, usually we uh use a browser to to simulate user behavior in giving in some scenarios and then we then we see whether uh is whether there is a deviation from the actual requirements to find out the bugs But in case of opponents testing and subsequently load testing, we don't have any browser, so we cannot actually check the UI. So, what we do is uh we test these types of tests are performed performed at protocol level. In these cases, we try to measure that what is the maximum capacity of the system.

Speaker 1: See uh if uh uh that is that is uh we are trying to determine the maximum upper limit of the number of users systems can handle. In these cases, we won't be considering actions which are performed by browser like JavaScript execution and all those. So uh locust IO provides us uh similar features. So it allows us to do the third testing of web applications and APIs. It's an open source tool and uh as Pranjal mentioned that uh we can write our tests in Python That's where our main advantages. Once we have written our test, it provides us

Speaker 1: a web-based UI to actually start our test and see the results If we don't want to use web-based UI, we can r run it in headless mode also Setting up uh locast iO is uh fairly simple. Um we we need uh we need any version of Python which is below 3. 9. It does not run with uh it does not run with Pi 2. 3. 9 and above. All we have to, if you want to install it, all we have to do is just run pip install locist command in our virtual environment. Once uh locust IO is installed, uh next step is to write a locust file.

Speaker 1: So in these uh in this locust file uh we try to define our users and uh and Write our scenarios V in form of Python classes which can be executed Once uh these uh this locust file has been written uh or to run the run the test, all we have to do is just uh run the locust command. Additionally, we can pass a host parameter which will uh which will uh which will define uh the application which we are trying to test. For example, in this uh case you can see mysite. com, which uh will be tested Let's look into the structure of locust file that we can uh create to

Speaker 1: start our load test So three main components of our locust file are task, task set, and users. Users actually represent the the users uh object of uh user class represent the users that we are trying to generate during our load test So these users will perform certain tasks for a particular scenario. We can group these tasks to actually uh uh group these tasks to actually represent a particular scenario that we are trying to test. So these uh users are when we actually when we are actually running the load test these users are generated uh randomly And uh

Speaker 1: and uh b based on the scenarios that we have written, uh the tasks are performed But uh addiction in real uh real life scenario, what happens that uh it may happen the users are users won't be Going through different scenarios in equal proportion, it may happen that some of the operations are performed more frequently than others So i in or i if you want to uh if you want to divide those uh tasks or scenarios in some sort of proportion uh Locustyo provides that option. So let's look into this piece of code where we have defined

Speaker 1: two tasks at one at line number six and another at line number 10 using task decorator. And additionally, we have provided uh a parameter. So this parameter three and five actually represent the weight of the task. It me it just means that uh these tasks will be executed in the proportion of five is to three.

Speaker 2: Okay , let me show you a quick demo for Locus Tio. So for testing, for doing load testing, we have developed a very basic Django application Which is having some basic operations like login, logout, and a scenario where a user can see the questions and they will be given four choices and They can select one of the choice and submit their answer. The answers will be recorded and the scores will be calculated and shown on the dashboard. So we have one more feature in this that is that dashboard. So I'll show you what all things we have included in our locust

Speaker 2: file To do the load testing on our this basic Django application. So as told earlier, we have a user class that is a class website user here. So this user this is a simulated user and uh this will do all the this will generate the load Next, we have a user behavior class, which is a collection of all the tasks that is a and it is extending task set So in the task we have few things like uh few methods like on start and on stop. So As the name suggests, onStart method will

Speaker 2: perform all the things that we need to do when before we start doing load testing on our on our application. So here I'm performing a login operation. On start. So as it makes sense, before uh trying to test load on my Django application, I want to log into my application. Next thing on stop method. So on stop I'm performing.

Speaker 1: We looked into one scenario where user was able to log in and fetch questions and Post responses for those questions. So we performed load testing for that particular scenario. Let's look into another scenario where user will log in and view the dashboard. So for the for creating a separate scenario, we could have uh we got we could have created a separate task set. Uh in this file, we we have not created a separate task test. Instead of that, we have included uh One more task at line number 31, where we have a method get dashboard. Okay. If you wanted to create a separate task task set, we could have just included it in

Speaker 1: uh at line number forty one. Okay, so for now we'll just uh I we have just com uncommented the get dashboard method And uh since uh we we will comment out uh get question post-answer methods so that uh it is not included in our scenario. So let's start our load test again and see what are the results that we are getting. So we will uh we have uh started our load test with 50 users at same spawn rate of ten So slowly users have increased and now it's uh up to 50. So if we can see that we are getting some requests for dashboard also.

Speaker 1: So so far there are 120 around 120 requests with median timers, median time of 23 milliseconds, and 98th percentile is uh 730 milliseconds, which means that 90 percent of requests. are under the this time. Average average response time is 183 milliseconds and minimum is 11 Yes, uh we will run this test for I guess uh wait till four hundred or five hundred requests It will it it will take some time. Meanwhile uh we can see that uh we uh we have we are gonna

Speaker 1: we have got one failure with login. Let's look into the Failure chart, what what is that? Okay, there is some server error. Maybe we can look into that later, but yeah, for now we can go back to our statistics and uh We have or slowly the as the number of requests is increasing, the average uh time response time is also increasing. Right now it's uh the two hundred. Okay. Maximum time is uh almost eighty-nine thousand that's that's using So

Speaker 1: instead of maybe four and five let's stop at three mark of three hundred requests Yeah, I think uh we can stop our load test here. And uh as soon as we stop our test uh log out Function is also called and if we go back to our console, we can see that snapshot of the test will be captured. So stop it for like yeah so whatever results uh we had seen on the dashboard that particular snapshot is captured here final Snapshot is captured here and uh we

Speaker 1: can see this result. So for this uh particular load test uh we when we we we were actually uh preparing for this, so Pranjil was saying that This is one scenario where we can actually get a better result. We looked into one scenario where uh user was able to log in and uh fetch fetch questions and Post responses for those questions. So we performed load testing for that particular scenario. Let's look into another scenario where user will log in and view the dashboard. So for the for creating a separate scenario, we could have uh we got we could have created a separate task set. Uh

Speaker 1: in this file, we we have not created a separate task test. Instead of that, we have included uh One more task at line number 31, where uh we have a method get dashboard. Okay. If you wanted to create a separate uh Tas uh task it, we could have just included it in uh at line number forty one. Oh yeah. Okay, so for now we will just uh we have just come uncommented the get dashboard method and uh since uh we we will comment out uh get question post answer methods so that uh it is not included in our scenario. So let's start our load test again and see what are the results that we are getting.

Speaker 1: So we will uh we have started our load test with 50 users at same spawn rate of 10 So slowly users have increased and now it's uh up to 50. So if you can see that we are getting some requests for dashboard also. So so far there are 120 around 120 requests with median timers, median time of 23 milliseconds, and 98th percentile is uh 730 milliseconds, which means that 90 percent of requests. are under the this time. Average average response time is 183 millisecond and minimum is 11 Yes, uh we will run this test for

Speaker 1: I guess uh wait till four hundred or five hundred requests It will it it will take some time. Meanwhile uh we can see that uh we uh we have we are gonna we have got one failure with Login. Let's look into the failure chart. What is that? Okay, there is some server error. Maybe we can look into that later, but yeah, for now we can go back to our statistics and uh We have or slowly the as the number of requests is increasing, the average uh time response time is also increasing. Right

Speaker 1: now it's uh the two hundred. Okay. Maximum time is uh almost eighty-nine thousand that 's that 's using So instead of maybe four and five, let's stop at three mark of three hundred requests. Yeah, I think uh we can stop our load test here. And uh as soon as we stop our test uh logout function is also called and If we go back to our console, we can see that snapshot of the test will be captured.

Speaker 1: So stop it for like. Yeah, so whatever results uh we had seen on the dashboard, that particular snapshot is captured here. Final snapshot is captured here, and uh we can see this result. So For this uh particular load test uh we when we we we were actually uh preparing for this, so Pranjil was saying that this is one scenario where we can actually get a better result. So I uh we uh so we looked into that part. Let's look uh let's check what what we have actually done in our views. py file and uh models So basically in this uh

Speaker 1: So basically in this uh in in this uh get method uh in this get get method we have We are just fetching all the test objects and returning it with the template. So let's look into the structure of test Model class. So test model class has a foreign key reference for users, some other fields like created date, end date, total time score, and active. Uh this user class. So for this particular user class uh since uh what what is happening is uh when

Speaker 2: Okay, uh so we have our Django application up and running, our local server up and running, and uh we perform load testing on our application under multiple scenarios. So we did load testing for 50 users, but what if we want to increase the load on our application and increase the number of users to maybe say 500 or thousands or many more. So in this case, um a single sub machine might not suffice. So for this to perform uh to test scalability of our system and uh uh check how much scalable our uh how much load test

Speaker 2: our system can handle under multiple machines Locust provides us a very out-of-the-box feature for uh load testing in uh distributed mode. So uh for this For this, we have a single locust master and multiple worker scenario configuration. What happens here is uh multiple workers generate the load. They perform a load test, they uh do load generation on our Application under the image of multiple simulated users and by default every three seconds they generate report and return uh

Speaker 2: submit those reports to the master The master, locust master collects all those reports and consolidates the data and shows us the results. So yeah. So for this we need to we need to run two commands. First of all, we need uh two locust files. one for master and one for worker. Those can be in multi uh same machine or maybe different virtual machines or whatever And we need to run the master command and mention the host of our application and the worker command. which will run workers and you need to link it to the master host.

Speaker 2: So you need to provide the host of your master So uh

Speaker 1: I think uh yeah. Yeah one thing here so this master host uh is given as my site. com so they don't uh go by this. Uh We uh it won't be in in first case where we have provided host as my site. com. That is the application which we are trying to load test. But in the second one, we are actually trying, we are actually providing host name of the Machine where we are running our master low pest. So it can be uh it will be different for us

Speaker 2: Yeah, correct. So uh to perform distributed load testing, we have uh we have run our applications in EC2 instances and uh yeah so one for master and uh we have run multiple Multiple workers here as you can see. This is the dashboard for distributed. It's uh everything same, just that you can check uh here the multiple workers are mentioned. Uh, right now we have two workers running. I'll start performing load testing for say maybe 250 users at the spawn rate of 25 Yeah, let's start swarming and attacking our website.

Speaker 2: So as you can see, the logins have started, the question URLs and the answer URLs are getting hit And uh yeah, so the same same way we have uh the response time The request per second here, everything is the same. You can check the charts here, real-time charts, the failures the exceptions and download the data in multiple formats. One extra thing here is you can check as you can see the workers tab here You can see the number of users distributed across both the workers, like we had entered 250 users

Speaker 2: and 125 users are working on each worker and the CPU users is mentioned. Yeah, so we already have 200 users here and we had entered 250. Let that let this run So what happens is uh the distributed load testing is done and the master locust will have all the data. Once that is done, you can check and analyze and perform and check the performance of your system and maybe increase it, improve it whenever and wherever needed.

Speaker 1: Okay, apart from uh primary features like uh uh defining different types of users or uh designing multiple scenarios or load testing in distributed mode, locust IO provides uh many more features. Uh some of these features are like uh Right now we have seen uh load testing for HTTP protocols. If you want to or do the same for other protocols, uh uh locust I can be extended for that also if you want to see Change the client that can also be done. So all these are documented on the official documents site. Link has been provided. We can see the link on this particular slide.

Speaker 1: So if you find this interesting, do visit the documentation and explore more. If you have any question, you can reach out to us on these email IDs. And if you have a

Speaker 2: So I hope you understood about how we can use Locust Io to load test our applications and you'll use it. Whenever you get a chance.

Speaker 1: Okay, so Amit has one question that uh what do you recommend for testing say a normal laptop or how many users can we test? And how will we know if the delay is our machine or application via CPU or network? Okay, so um So

Speaker 3: Amit to answer this, you can use as many users as you want. As this is load testing, we want to check how many users our application can handle. And for each request it will the locust dashboard will show the CPU usage and the response time and request per seconds I hope this answers your question.

Speaker 1: I think even in uh when we do load testing with other tools um like load runner or uh new load, so we are able to do it on our laptops itself. Yeah. So it depends on the type of application also. So uh normally like uh in uh the type of application which I am working on right now, so I usually I look for We look for support up to 200 to 50 users per second. So in that case, when we are trying to simulate that kind of behavior, we are able to do it directly on our laptops. Okay, Piuse has uh one more question. Uh how to identify the upper limit of users that we can test

Speaker 1: with locust on local machine. I am not exactly sure about this part as of yet. I will check and uh maybe uh okay so uh if we are uh if we are trying to test uh any particular scenario So in that case what we usually do is uh there are there are two ways. Either if we have already uh faced similar scenario, then in that case uh we use prior experience to decide number of users For load testing, otherwise, if there is uh no

Speaker 1: uh no prior experience, then in that case uh uh analysis is done by the business to uh understand that how many users are we expecting. So uh on basis of that we uh we We decide the number of users and from there on uh if say if you want to uh if you want to Test it for large number of users uh we can we can use multiple machines or if it is lower number then we can go for single machine. But how many to do on a single machine that part I'm not sure of And uh this is uh one of the skills that uh that comes with performance testing is to

Speaker 1: actually identify the number uh actually I uh find out the number of users that uh will be That will be uh that should uh number of users that should be simulated during load test. Okay uh There is another question. Can I also do the load test with more complex web application? And how would I do that? Okay, so uh if we look into the uh look into uh other load testing tools that we have in market, so one of the key feature that is uh that is uh available with uh other tools is uh record and play feature. So basically whatever so if you want to if you want to

Speaker 1: Simulate a scenario. So that scenario we run manually, and the tool itself records that particular scenario. It uh it captures all the network calls that are going through, and then those can be uh used for uh those can be used for further uh further test setup uh that feature is not available with uh locust io Uh if we are able to uh if uh uh there are alternatives, we can uh if we are able to uh uh do uh capture the network calls for a particular scenario, then in that case uh after After recording play, we uh we run into uh first is scenario design for a scenario design, then uh for for a particular scenario we want to do parameterization

Speaker 1: correlation these things so for uh any complex as application as long as uh if we are able to do these three things I think we can continue with the load testing. So scenario design, parameterization, correlation, all three can be done with with uh locust i also also uh like we should uh we mentioned in the video uh for scenario design we can uh we can distribute uh we can create multiple task sets and uh and those and uh actually divide our uh our uh our entire flow into different tasks group into task set and then Those task can be cre uh can be uh used as uh uh can be used to actually simulate a particular scenario.

Speaker 1: So once that is done, and uh once that is done, then after that uh we would want to uh if you want to make it uh closer to real time. So in that case we we would like to have uh like different weights for particular you uh particular tasks or even for the users So I think uh uh different rates for users that was not mentioned, but uh that also we can do. So that helps in uh uh us in modeling the test closer to real time. Uh what uh apart from that I mentioned parameterization where where uh say if you want to like uh we had shown that if you want to uh get csrf token so that can be one parameter for a particular used uh user

Speaker 1: so that that can also be configured since uh since we are using python here so we can uh we can directly code all those things uh and then uh then we can uh we can have say uh if you want to uh we want to test with 200 users then in that case uh if you uh we can have 200 uh 200 user credentials and then keep it in uh then uh keep it in a list and uh use that list to actually assign users to different types of scenario or even uh If you want, uh we we can we can uh divide it into percentages and uh try to simulate complex uh flows.