Hi, Xano Community! Today, I want to share a basic step-by-step on how to use Loader to test your Xano APIs. Testing is an incredibly important piece of launching any application, whether you are using Xano or not. It's important to understand how much traffic your backend can handle in its current state to ensure a smooth experience for your users once your project goes live.
I do of course want to preface this by saying that I am not an expert on this process. I'd love to have a discussion in this thread with the community and find out if there are any holes in my own process, find out what tools you like to use, and hear more about how you are all load testing your applications.
For my own learning, I chose to use a service called Loader, created by SendGrid Labs. My example backend is on the Scale plan, and is a backend created as a barebones Instagram-style application, allowing users to sign up, log in, view photos, post comments, and add new photos.
Getting Started
First, you'll need an account. Loader offers a free version as well as competitive pricing if you need features associated with their paid plans. Depending on your needs, the free account can be sufficient.
Before you can use Loader, you need to verify your host. This means that you're essentially proving you own the domain that you'll be utilizing to test with. This does mean that you need a custom domain linked to your Xano instance to continue. You can verify via one of two methods, DNS or HTTP. To break these different methods down, essentially we can either add a "tag" to our domain's metadata directly, or upload a file to our domain to serve as verification. In my case, using file verification was easier, and I was able to upload the file that Loader provided to my server and quickly pass Loader's verification process. If you're not sure how to do this, the process is going to be different for everyone based on the service that powers their domain and server, so I recommend reaching out to your domain registrar and/or web host for more information.
Building Your First Test
Once your host is verified, we can head into the Tests section and begin creating our first test. It's important that you understand the typical 'flow' a user would complete when visiting your application. I like to use an app called Excalidraw to quickly map these out. Here's an example:
Once I have this mapped, I can build the test in Loader by navigating to my Tests section, and creating a new test.
Give your test a name, and choose your preferred test type. Each test type is helpful for different scenarios.
Clients Per Test will test a scenario such as "How does my app perform if x number of clients connect over a certain period of time"
This means that we'll run through each request in the test once per user, over the course of the period of time you select.Clients Per Second will test something similar to "How does my app perform if x number of clients connect each second for a period of time"
This means that we'll run the test each second based on the number of clients you wish to test with.Maintain Client Load will test "How does my app perform if x number of users are logged in and using the app at the same time"
This means that we'll continuously run the test for each user repeatedly over the course of the test.
Once you've chosen your test type, you can start adding requests! I recommend reading up on Loader's own documentation on building tests and how to use variables to ensure you can test certain flows properly. Add the requests to your test in the order that you expect a user to perform them in -- you can refer back to the flow you mapped out earlier to make sure everything is in order.
When you're ready, you can run the test, save it for later, or schedule the test.
Interpreting Test Results
Reading the test results can definitely feel overwhelming, but there are a few key things you'll want to understand here.
You can use the Filter menu to drill down to specific APIs and view their individual statistics, or use -All URLs- to view the test as a whole. This specific test was a Maintain Client Load test, which means that we fired off a massive amount of requests for 5 - 10 clients over the course of 1 minute.
We can also use the graph to get a quick birds-eye view of how the test went. We can see while our response time (the blue line) did increase a little as new clients were added (the green line), overall, we stayed pretty steady. That's great news.
In my experience, Loader was providing higher response times than what Xano was reporting. This isn't necessarily strange, as we would expect any front-end to add additional time on to the full length of "when is the request complete", but I do recommend looking at your request history in Xano after running your test to get an idea of what the difference is in your specific scenario, and understand that depending on your front-end, your response times could be faster or slower than what Loader is reporting by testing your APIs directly. Here's an example below -- we can see that during this test, the response times reported by Loader are in some cases significantly different than what Xano is reporting.
How do I action APIs that are slower than I'd like?
This is the big, important question here, and the answer is it depends. There are a number of reasons why your APIs aren't as fast as we'd like, and it will require some investigation to figure out where adjustments can be made. We have a full guide on troubleshooting performance in our documentation, but here are some quick tips.
Use indexing on large tables that you are querying.
Indexing can be a night-and-day difference when you're running custom queries on large tables. It's similar to the index in the back of a book; instead of searching through every record in your table for the information you want, the table knows exactly where to go and can return that information much faster.
Use response caching for APIs where the response changes infrequently
Response Caching can be super helpful if you have APIs that are called frequently and/or return large amounts of data, but the data doesn't change very often. This allows Xano to essentially "skip" the function stack and just return the same response each time the API is called, until the cache needs to be updated, based on parameters you specify.
Reduce the amount of loops and conditionals in your function stacks.
This is super subjective depending on what you're trying to accomplish, but a couple of typical scenarios we see is users utilizing loops to merge multiple queries together into a single response when they could be using addons, or using stacked conditionals to determine information to update in an Edit Record step instead of conditional set filters.
Upgrade your Xano plan.
It's the answer we all hate, but sometimes, it's the right answer. Each Xano plan is allocated a certain amount of resources, and what you're doing in Xano may require a higher tier plan. If you're ever not sure if it's the right time to upgrade, feel free to reach out to support. We're happy to help review this with you and provide guidance on what would work best for you.
Wrapping Up
Remember, there are a ton of different services and tools you can use to test your APIs. I'm pretty new to this, and would love to hear about how you test your own backends.