Previously, our load testing process heavily relied on manual intervention using JMeter, where we manually modified the article and Token ID in the JMeter suite and exported results in CSV format which were then transferred to Excel sheets for analysis during each release. Despite providing us with basic insights like average response time and API throughput, this approach lacked the efficiency and scalability necessary for conducting comprehensive load testing. Furthermore, the time-consuming process of comparing post and pre-deployment results in Excel graphs became a daunting task and hindered report maintenance.

Performance Optimization – Parameterized Azure Load Testing

To overcome these limitations, we embraced the Azure Load Test for our Document360 product, where we harnessed the capabilities of Azure virtual machine infrastructure. By configuring JMeter within a virtual user environment, we unlocked a world of possibilities for load testing. Parameters like the number of threads, ramp-up period, and loop count ensured accurate simulation of user behavior, while response time metrics and error thresholds brought crucial performance insights to the forefront.

With Azure Load Test, we have the flexibility to configure our load testing setup based on specific modules. This enables us to perform testing on various load testing patterns (such as Stress, Spike, ramp up, Soak, and more) to meet specific application requirements. Whether we need to simulate high loads, stress test critical components, or analyze performance under different scenarios, Azure Load Test’s module-based configuration empowers us to tackle diverse testing challenges with ease.

Scalability and Cost Efficiency

Azure’s virtual machines proved to be the perfect ally for load testing. Their scalability allowed us to adjust resources on the fly, without the need for hardware changes. With pay-as-you-go pricing, we only paid for the duration of the load testing, eliminating the need for dedicated hardware investments. Resource isolation ensured reliable results, while environment replication guaranteed consistency across different setups. Rapid provisioning, simplified setup, and test repeatability streamlined the testing process, saving valuable time and effort. Centralized management tools provided easy control, monitoring, and troubleshooting, simplifying the management of our load tests.

Schedule a demo with one of our experts to take a deeper dive into Document360

Book A Demo

Real-Time Insights and Optimization

With Azure Load Test’s client-side and server-side dashboards, we unlocked real-time monitoring of API performance. Each API’s performance could be tracked and analyzed, allowing us to make data-driven decisions. Comparing test results became effortless, enabling us to identify deviations and improvements across different test runs. By passing parameters like bearer tokens within Azure itself, we simulated real-world scenarios accurately, ensuring our load tests reflected actual usage patterns. The seamless integration with JMeter allowed us to upload comprehensive JMeter suites, empowering us to analyze performance metrics and optimize our application’s performance effectively.

Benchmarking and Comparison

Response time metrics allow for benchmarking and performance comparison across different releases, environments, or competing applications. By establishing baseline response time metrics, we can track the application’s performance over time, assess the impact of changes or optimizations, and make data-driven decisions for future improvements.

Re-Running Tests for Continuous Improvement

But the power of Azure Load Test didn’t stop there. When changes were made in the same pre-release deployment, we could easily re-run the same test, validating the effectiveness of our fixes and improvements. This iterative testing approach paved the way for continuous improvement, ensuring our application met performance expectations.

Insights and Recommendations from Azure

Azure Load Test took our performance testing to the next level by providing insightful recommendations for improving our application’s resiliency. No more digging through logs or struggling to identify bottlenecks. Azure itself suggested solutions, allowing us to optimize our application effortlessly. The resiliency report provided valuable insights into the application’s ability to handle unexpected failures and recover gracefully.

With Azure Load Test’s result dashboard, effortlessly share comprehensive test results via a convenient link. Stakeholders can access and review detailed monitoring information with ease. Furthermore, you can download the test result logs and input files from each test run for further analysis and investigation. Here, we share a sample report of the Constant Load Pattern to provide an overview of the recent release. Where the response time and throughput for the Virtual User (VUser) configuration remained the same at 600ms with no deviation. This suggests that the release did not introduce any significant performance issues.

Conclusion

In this blog, we have demonstrated how we have improved our load testing in Document360 by leveraging Azure load testing. We have also added more scalability, cost efficiency, benchmarking capabilities, and real-time insights into our application load testing. 

An intuitive knowledge base software to easily add your content and integrate it with any application. Give Document360 a try!

GET STARTED

The post Revolutionizing Load Testing with Azure Load Test appeared first on Document360.

Because APIs have no front end, the docs are the UI. Developers count on up-to-date documentation available in an easy-to-read format, so they realize how an API works, and how to implement it into their code. In a nutshell, without docs, developers can’t use an API.

How do we create a delightful developer experience? Document360 has now extended its support to API Documentation. In this blog, we will look deeper into how to use the module efficiently.

API Docs allows you to describe and document your APIs. Enriching the Feature, it is possible to upload multiple API Definitions, which can then be used to generate interactive documentation, client libraries, and other artifacts. In addition to uploading an API definition file in JSON or YAML format, you can also use a hosted URL to import an API definition into API Docs.

How it works?

Create a specification for an API that defines how the API should function and what it should do. This includes defining the endpoints (URLs) that the API exposes, the request, and response formats the API uses, the HTTP methods that the API supports (e.g., GET, POST, PUT, DELETE), and any authentication or authorization requirements that must be met to use the API.

Some various tools and approaches can be used to design an API, including visual modeling tools like Swagger and Postman, and design-first approaches like OpenAPI and RAML. These tools allow you to define and document your API in a machine-readable format, such as JSON or YAML, which can then be used to generate documentation, test cases, and code for implementing the API.

Once you are satisfied with the API definition, Navigate to API Docs then select New API or Get started by adding your OpenAPI (OAS/Swagger) file by clicking the New API reference button. The blade will be opened with the options where the source can be selected based on the format you want to use, if you have a hosted URL then pick the option and enter the hosted API URL. We recommend using HTTPS (Hypertext Transfer Protocol Secure) rather than HTTP (Hypertext Transfer Protocol) for API communications, as HTTPS provides an encrypted connection that helps to secure data transmitted between the client and server.

OpenAPI 2.0 was the first version of the specification, and it is still widely used. OpenAPI 3.0 is the latest version of the specification, and it introduces several new features and improvements over the previous version. You can use either version to define your API.

Using an interactive interface by providing a clickable “Choose file” button or a drag-and-drop, it is more convenient to upload files, without manually entering the file path or using the command line to upload the file.

View Logs – Errors and warnings

It is common to encounter errors and warnings when uploading or updating an API definition, especially if the definition is large or complex. These errors and warnings can occur for a variety of reasons, such as syntax errors in the API definition file, missing or incorrect information in the definition, or conflicts with other API definitions or resources.

It can be helpful to show errors and warnings separately when managing API updates, you can more easily identify and prioritize issues that need to be addressed and can take steps to fix them promptly.

To help manage and track these errors and warnings, the “View logs” option is provided for every API Definition to maintain logs of API updates. To access this, navigate to API Reference select any API menu, and the View Log option is found with the records of the date, time, and details of each API update, along with any errors or warnings that occurred. This can allow you to identify and troubleshoot problems with your API definition, and to track changes and updates to the API over time. Instead of Manual maintenance, it is possible to generate a log of API updates in CSV format with more specific details of operation type, imported by, date time, error, and warning message as well as the path, to identify and resolve any issues that may arise.

Also read: API Lifecycle Management: Everything You Need to Know

Import API Definition File Types

It is important to consider the capabilities of different file types when choosing the file type for a given task. The File Type is mentioned as File Upload, and the URL has the Resync and the API Definition options. If there are changes to the API schema while updating the API definition file and then regenerating the API client or server code, you can resync the schema to reflect those changes immediately. Similarly, if you have an API client that consumes an API and you want to make sure it is up to date with the latest schema changes, you can update the API definition file. This will ensure that the server code is consistent with the updated API schema.

View API Definition option for URL is provided to know how the API is implemented and how the definition is stored. This can be especially useful if your API is constantly changing or if you have multiple versions of your API in use at the same time.

Ready to take your API documentation to the next level? Book a demo with Document360 today!

Book A Demo

API Documentation Editor

Once the API Definition has been uploaded, it categorizes and creates endpoints into documentation articles in an interactive way, which can be a useful resource for developers who want to use your API. The documentation generated from an API definition typically includes a list of available endpoints, a description of the parameters and request/response formats for each endpoint, and examples of how to use the endpoint. Also allow you to include additional information, such as code samples and explanations of how the API works. Typically, now the API Definition is treated like a Document360 article where the endpoint article can be easily renamed, hidden, delete, and can move to other API Definitions if needed. Supports a wide range of endpoint types, including GET, POST, PUT, DELETE, and many others. You can view the available endpoints, the parameters that each endpoint expects, and the responses that each endpoint returns.

Invoking an API using API Documentation

In addition to specifying the endpoints of an API, API Documentation also supports a range of other features, such as authentication, authorization, and error handling. It can be used to design APIs for web, mobile, and other types of applications.

Once the Category is Published in the Portal, it can be navigated to the KB site where the operations can be performed. The same Category tree view with Endpoints was displayed. You can use the dropdown menus in the Editor server to select the HTTP method (e.g., GET, POST, PUT, DELETE) and the endpoint that you want to test. To make a GET request to an API endpoint using basic authentication, you will need to provide your client ID and secret key as the username and password, respectively.

This can typically be done by selecting the “Basic Auth” type in the API client or integration that you are using. Note that the required Parameters were passed in the Try it panels. The Authentication details were stored in Cache for future requests to the API by including it in the request header, this helps seamlessly and time-saving workaround. Use the credentials to request an API token. This typically involves making a POST request to an authentication endpoint and passing your credentials in the request body. The API provider will then verify your credentials and, if they are valid, return an API token in the response.

Enter any required parameters in the form fields provided. Click the “Try it out” button. This will send a request to the API endpoint and display the response in the HTTP status code and the response payload (if any) in the right-hand panel. You can use this information to determine whether the API is functioning as expected. Review the response in different formats, such as JSON, XML, or HTML. The content type of response is specified using the “Content-Type” header in the HTTP response. For example, if the response includes data in JSON format, the “Content-Type” header might be set to “application/JSON”.

The content type of a response can be important for several reasons. For example, it can be used by the client to parse and interpret the data in the response. It can also be used by the client to determine how to process the response, such as by rendering it in a web browser or displaying it in a mobile app.

In some cases, an API may support multiple content types for a single endpoint. For example, an endpoint might support both JSON and XML formats, and the client can specify which format they prefer by setting the “Accept” header in the request. The API can then use the “Content-Type” header in the response to indicate the format of the data that was returned. Repeat steps 3-6 to test additional endpoints or to test the same endpoint with different parameter values. Overall, using API Documentation to invoke an API is a simple process that allows you to test the functionality of the API and understand how it works.

Response Examples:

In API Documentation, you can specify examples of responses for each endpoint in your API. This can help document the API for testing purposes.

Here is an example of how you might specify a response example in Swagger for an endpoint that returns a list of users in JSON format:

/users:

  get:

    summary: Retrieve a list of users

    responses:

      200:

        description: Success

        content:

          application/json:

            schema:

              type: array

              items:

                $ref: '#/components/schemas/User'

            examples:

              user-list:

                value:

                  - id: 1

                    name: John Smith

                    email: john.smith@example.com

                  - id: 2

                    name: Jane Doe

                    email: jane.doe@example.com

In this example, the endpoint is named “/users” and it supports a GET request. The response includes a 200 status code, which indicates success, and the data is returned in JSON format. The “examples” field includes an example of the response data that might be returned.

You can also specify multiple examples for a single endpoint, each with a different set of data. This can help demonstrate how the endpoint behaves under different conditions or with different input data.

The example I provided in the previous response is intended to show how you can specify a response example in Swagger for an endpoint that returns a list of users in JSON format. It is not intended to be a complete API definition or to be used as-is to generate code or other artifacts.

To generate code or other artifacts from an API definition, you typically need to provide a more complete and accurate representation of the API, including details about the endpoints, parameters, request and response formats, and other aspects of the API.

Code Samples

Code Samples allow developers to generate client libraries for an API in a variety of programming languages. Supports Shell script, Python, Java, JavaScript, and C# making it easier for developers to consume the API. Using this generated code, it is possible to import the client library into your application and use it to make requests to the API.

Overall, obtaining and using API Documentation is an efficient way of interacting with an API, and can help you automate this process and generate code snippets for the API.

Last thoughts

API documentation is becoming well and better as more and more companies recognize the significance and devote the appropriate time and resources to the process. The next time you need to create quality API documentation, check out Document360 API documentation to make your job easier. We pride ourselves on taking the difficulty out of API documentation, and we look forward to assisting you with your efforts.

Ready to take your API documentation to the next level? Book a demo with Document360 today!

Book A Demo

The post Create an enchanting API developer experience with the documentation appeared first on Document360.