Microservice Patterns and Best Practices: Explore patterns like CQRS and event sourcing to create scalable, maintainable, and testable microservices

The first goal for a software developer is to achieve proficiency in any programming language or paradigm. Achieving a good level of proficiency is not easy, and some languages may have a steeper learning curve than others.

Problems arise when proficiency in a language ends up creating a comfort zone from which a developer or team finds it difficult to leave. In contrast, a myth must be overthrown: that one programming language is much easier than the other. Obviously, a language may prove simpler than another at first, but in the end what will count is the practice time and the number of scenarios experienced by a developer with a programming language.

Another myth that must be fought is that all languages are equal at their core and that only the syntax changes. This is one of the worst possible errors that can be committed. Languages can be quite different in internal design and performance, although they have similar syntaxes.

Proficiency is something that should be considered when deciding which language to apply for a microservice. However, it should not be as decisive as this one.

This is a key requirement in choosing a programming language for a microservice. When we talk about performance for microservices, there are many points where performance can be a problem: the network communication layer, access to the database, where the servers are available. All these points can be problematic for microservices. The programming language cannot be another can of slowness.

When the target is microservice performance, no matter the skill of the development team, it should be used for best second language benchmarks and stress tests.

Something that often creates misunderstanding is considering the speed of a development team to implement a feature and performance requirement. Performance is related to a metric similar to how a code behaves when responding to a request or performing a task. Definitely, personal or team performance is not included in this metric.

This is the requirement responsible for measuring the speed applied to a feature going into production. Development of practicality touches two teams: the development team that already exists and the development team that can come into existence.

As has been said before, the word success can be a problem for an application and consequently for the product owners. Keeping the base code simple and understandable is fundamental to facilitating code changes and for implementing new features.

Good programming practices can help us to understand the legacy code, but often the language itself, because the verbiage is not very friendly.

There are scenarios where a programming language, given its characteristics, is extremely performative. But the cost of time to implement something new, though it may be simple, can be very expensive.

Think of a scenario where a start-up has just launched its product. The product is also a Minimum Viable Product (MVP) and was launched in the market to go through public validation in general. If this MVP succeeds, it is essential to publish new features as quickly as possible. In this case, the performance is not the problem, but the practicality of new interactions on the code.

When we are developing microservices and we decide to use this programming language it is an important aspect to be noted.

The ecosystem of a programming language is a crucial one.

We all know that parts of the frameworks are almost essential to gain speed and simplicity in the development of any application. With microservices, the scenario is identical.

It is feasible that features are not developed by something being blocked on the technical side. Of course, the microservices architecture is providing a plurality of very broad tool options. However, understanding the possible drawbacks when choosing a programming language, and therefore inheriting its ecosystem, is critical to the engineering team responsible for the implementation.

There are cases where a programming language is very performative, but the ecosystem that would win on development speed compromises performance. This type of situation is far more common than you think.

Another point is when a language is very simple, but the frameworks are not mature enough; you end up generating unnecessary complexity.

Observing the ecosystem of a programming language, and understanding the risks it is assumed we gain by inheritance, is fundamental to the adoption of a language.

The cost of scaling an application is linked to two major factors. The first is the speed of the selected stack used to implement the software. Specifically, the speed and capacity of processing algorithms and answering requests. The second factor is the ability to scale the application of the business part. How long is it applied to features and especially the predictability of new features? The time to create something new or redesigning something that already exists is also expensive.

With microservices architecture, the cost of scalability is usually related to the concept of having smaller areas and parts which are less integrated. Even then this cost is very important.

Think of two applications, one with strong interactivity with the end user, such as an online game or editing documents in real time. Another application is fully illustrative, has an editorial part, but is not open to all users; a newspaper or streaming provider are good examples.

The application of real-time data processing and response time to requests must be fast and dynamic. In the second, application processing, it is not something that has much relevance, as the information may be in a cache or statically stored.

The cost will be high when you do not understand the nature of the microservice to be developed.

Because this is the point to choose a programming language for microservices and applications in general, we will apply this knowledge to select which programming language we use in each area of our service.

We know that our news portal has the following areas:

Given our fields of business, we can divide them by similarity of features. SportNewsService, PoliticsNewsService, and FamousNewsService have similar behavior. These microservices are news providers and are more focused on the consumption of data than receiving information.

These microservices may have an identical starting stack, which does not mean they should always be identical or that they need evolve in the same direction. Regarding the programming language, performance is not as crucial, but the speed of change and implementation of new features is crucial.

RecommendationService is very different from the other microservices. There is no direct interaction between the end user and the application. Nor is there a direct interaction between the editorial area and this software. RecommendationService is a support microservice; there are other microservices and all the interactions and operations are on  the technical side. Loading and interaction occur completely asynchronously, but processing will certainly be higher than in other microservices. However, this is not a real-time application.

UserServices is a microservice with dynamic interaction on all sides, both for the end user as well as the editorial layer. The information from UserService may also be consumed by the other microservices such as RecommendationService. It is noteworthy that on this layer, caches can be dangerous, providing wrong information if they are not correctly invalidated. As UserService is a microservice that supports a direct relationship with the internet, it leads us to a programming language that has the speed of response for requests, processing speed, simplicity in implementing features, and good asynchrony APIs.

With the characteristics of each sector in mind, it is the time to think in a completely practical way to select a programming language that applies to each microservice. Let's consider each of the five aspects mentioned at the beginning of the chapter associated with the nature of the issues.

Comparing programming languages is complex, but in this case, we need to make choices. Many languages could be compared. However, for our application, we have chosen five for the comparison based on popularity, personal experience, documentation, and actual cases of applicability. The languages are Java, C#, Python, JavaScript, and Go.

Go

Go is a compiled programming language and has great performance. No doubt it is one of the languages that has seen growing popularity in recent years. Go is a language with the imperative paradigm, although very few developers understand that there is some level of OOP. The ecosystem's main characteristic is a standard robust library, making frameworks in some cases unnecessary. But the ecosystem is not perfect, with problems in simple things like version control. Go has simple and easily readable syntax. The main feature of the Go syntax is the convenience that it applies and how it handles concurrent programming.

To make it easier to compare, we will use the following chart as support:

In the case of our news portal, these are the languages that will be applied:

• SportNewsService, PoliticsNewsService, and FamousNewsService: These microservices make use of Python. It is the typical scenario where language applies very well. The lower performance of Python will not be a problem even if the portal receives many hits.
• RecommendationService: This application also uses Python. This choice is fully related to a connection between performance and practicality in using other tools that will make the stack of our microservices. A microservice like this does not have the requirement of being real time; we can use something that has simplified APIs and is not as disruptive to the rest of the ecosystem.
• UserService: These microservices apply Go. UserService is a microservice that interacts with users as well as providing information to other application microservices.

The fact is that there is no perfect tool for everything. All languages have shown positive and negative points. With the great technological plurality that we can apply to the microservices architecture, managing the stack that best applies in each scenario is our role in this case.

In the world of Python, there is a multitude of interesting frameworks; Bottle, Pyramid, Flask, Sanic, JaPronto, Tornado, and Twisted are some examples. The most famous that has more support from the community is Django.

Django is the same framework that was used to build our news portal in the monolithic version. It is a very good tool for full-stack applications and has, the main characteristic, and the simplicity to mount this type of software.

However, for microservices, I do not think it's the best framework for this purpose. Firstly, because the exposure of APIs is not native to Django. The ability to create an API with Django comes from a Django app called Django Framework Rest. In order to maintain the standard structure of the Django framework, the design of a simple API was a bit compromised. Django provides the developer with the entire development stack, which is not always what you want when developing microservices. A more simplistic and more flexible framework for compositions can be interesting.

In the Python ecosystem, there are other frameworks that work very well when it comes to APIs. Flask is a good example. An API, Hello world, is made in a very simple way.

Installing Flask with the command:

$ pip install flask

Writing the endpoint is very simple:

# file: app.py# import de dependenciesfrom flask import Flask, jsonify

Instantiating the framework:

app = Flask(__name__)

Declaring the route:

@app.route('/')def hello():    #Prepare the json to return    return jsonify({'hello': 'world'})

Executing the main app:

if __name__ == '__main__':    app.run()

The preceding code is enough to return the message hello world in JSON format.

Other frameworks were inspired by Flask and worship the same simplicity and very similar syntax. A good example is Sanic.

Sanic can be installed with the command:

    $ pip install sanic 

The syntax is almost identical to Flask, as can be seen in the following code:

# file: app.py

Importing the dependencies:

from sanic import Sanicfrom sanic.response import json

Instantiating the framework:

app = Sanic()

Declaring the route:

@app.route("/")async def test(request):    #Prepare the json to return    return json({"hello": "world"})

Executing the main app:

if __name__ == "__main__":    app.run(host="0.0.0.0", port=8000)

The big difference between Flask and Sanic is the performance. The performance of Sanic is much higher than Flask due to use of newer features in Python and the possibility of the exchange of the Sanic framework. However, Sanic is still not as mature and experienced in the market as Flask.

Another plus point for Flask is the integration with other tools like Swagger. Using the two together, our APIs would be not only written but also documented appropriately.

For microservices using Python as a programming language, performance is not the most important requirement, but practicality. Use this framework as Flask microservices.

This is a totally different Python case. While most Python frameworks help with performance and try to provide the best possible environment for development, Go is not the same. Usually, frameworks with many features end up compromising the performance of the language.

Running 10s test @ http://localhost:8080  4 threads and 16 connections  Thread Stats   Avg      Stdev     Max   +/- Stdev    Latency   447.99us    1.59ms  27.20ms   94.79%    Req/Sec    37.13k     3.99k   47.86k    76.00%  1478457 requests in 10.02s, 1.03GB readRequests/sec: 147597.06Transfer/sec:    105.15MB

The first step is to understand the functioning of the microservice to know what kind of communication best applies. Take, for example, the microservice recommendations. It is a microservice that has no direct communication with the customer, but traces a user's profile. No other application point expects an immediate response arising from this microservice. Thus, the communication model for this microservice is asynchronous.

Very well! We saw that RecommendationService is not a synchronous case; then what is?

The answer is UserService. When a user enters a given API that communicates with UserService, this user sees the change immediately. When a microservice requests some information on the requested UserService, we want the most current information possible and immediately. Yes, UserService is a service where synchronous communication can be applied.

But how can we create a good layer of synchronous communication between microservices? The answer is right in the next section.

service Greeter { 

  rpc SayHello (HelloRequest) returns (HelloReply) {} 
} 

    message HelloRequest { 
      string name = 1; 
    }  

    message HelloReply { 
      string message = 1; 
   } 

$ python -m grpc_tools.protoc -I../../protos --python_out=. --grpc_python_out=. ../../protos/file_name.proto

    typedef i32 MyInteger 
 
    const i32 INT32CONSTANT = 9853 
    const map<string,string> MAPCONSTANT = {'hello':'world', 
          'goodnight':'moon'} 
 
    enum Operation { 
      ADD = 1, 
      SUBTRACT = 2, 
      MULTIPLY = 3, 
      DIVIDE = 4 
    } 
 
    struct Work { 
      1: i32 num1 = 0, 
      2: i32 num2, 
      3: Operation op, 
      4: optional string comment, 
    } 
 
    exception InvalidOperation { 
      1: i32 whatOp, 
      2: string why 
    } 
 
    service Calculator extends shared.SharedService { 
      void ping(), 
      i32 add(1:i32 num1, 2:i32 num2), 
      i32 calculate(1:i32 logid, 2:Work w) throws
           (1:InvalidOperation ouch), 
      oneway void zip() 
    } 
 

    service Calculator extends shared.SharedService { ...  

   $ thrift -r --gen py file_name.thrift

Direct communication between microservices may result in a problem known as Death Star. The Death Star is an anti-pattern where there is communication between the recursion microservices, and making progress becomes extremely complicated or expensive for a product.

With the communication tools we saw previously, it is very easy to establish conversations between microservices with low latency. The common anti-pattern is to allow microservices to exchange messages with each other freely, if they have no information to process a specific task.

This is where we have an alert. If a microservice always needs to communicate with another to complete a task, it is a high coupling signal and we have failed in our DDD process. This engagement results in a Death Star. For clarity, consider the following scenario.

Imagine that we have four microservices. The microservices are A, B, C, and D. A request was made asking for information about A, but it does not have all the information content. This content is in B and C, but C does not have all of the information, so it asks D. B is not able to complete the task assigned to him and asks for data from C. However, D needs the data in A. The following is a diagrammatic representation of this process:

In the end, a simple request generates a very complex flow, where any failure is difficult to monitor. Apparently, it may seem natural, but over time and with the creation of new microservices, it makes this ecosystem unsustainable.

The microservices must be sufficiently well defined in their respective responsibilities for this type of messaging to be minimized.

No matter how fast the communication and serialization information is, if the product is not humanly intelligible and understandable, it will be very difficult to maintain the ecosystem of microservices, especially with regards to error control.

ActiveMQ is extremely traditional and very experienced. For years it was like the standard message bus in the Java world. There is no doubting the maturity and robustness of ActiveMQ.

It supports the programming languages used in the market. The ActiveMQ problem is related to the most common communication protocol, STOMP. Most mature libraries use ActiveMQ STOMP, which is not one of the models of sending more message performers. The ActiveMQ has been working on OpenWire for a solution in place of STOMP, but so far it is only available for Java, C, C++, and C#.

The ActiveMQ is very easy to implement, has been undergoing constant evolution, and has good documentation. If our application, the news portal, was developed on the Java platform, or any other that supports OpenWire, ActiveMQ is a case to be considered carefully.

RabbitMQ uses AMQP, by default, as the communication protocol, which makes this a very performative tool for the delivery of messages. RabbitMQ documentation is incredible and has native support for the languages most used in the market programming.

Among the many message brokers, RabbitMQ stands out because of its practicality of implementation, flexibility to be coupled with other tools, and its simple and intuitive API.

The following code shows how simple it is to create a system of Hello World in Python with RabbitMQ:

# import the tool communicate with RabbitMQ 
    import pika 
    # create the connection 
    connection = pika.BlockingConnection( 
      pika.ConnectionParameters(host='localhost')) 
    # get a channel from RabbitMQ 
    channel = connection.channel() 
    # declare the queue 
    channel.queue_declare(queue='hello') 
    # publish the message 
    channel.basic_publish(exchange='', 
                      routing_key='hello', 
                      body='Hello World!') 
    print(" [x] Sent 'Hello World!'") 
    # close the connection 
    connection.close() 

With the preceding example, we took the official RabbitMQ site, we are responsible for sending the message Hello World queue for the hello. The following is the code that gets the message:

    # import the tool communicate with RabbitMQ 
    import pika 
  
    # create the connection 
    connection = pika.BlockingConnection( 
    pika.ConnectionParameters(host='localhost')) 
 
    # get a channel from RabbitMQ 
    channel = connection.channel() 
 
    # declare the queue 
    channel.queue_declare(queue='hello') 
  
    # create a method where we'll work with the message received 
    def callback(ch, method, properties, body): 
      print(" [x] Received %r" % body) 
 
    # consume the message from the queue passing to the method 
          created above 
    channel.basic_consume(callback, 
                          queue='hello', 
                          no_ack=True) 
 
    print(' [*] Waiting for messages. To exit press CTRL+C') 
 
    # keep alive the consumer until interrupt the process 
    channel.start_consuming() 
 

The code is very simple and readable. Another feature of RabbitMQ is the practical tool for scalability. There are performance tests that indicate the ability of RabbitMQ in supporting 20,000 messages per second for each node.

Kafka is not the simplest message broker on the market, especially with regards to the understanding of its inner workings. However, it is by far the most scalable and is message broker performative for the delivery of messages.

In the past, unlike ActiveMQ and RabbitMQ, Kafka was not sending transactional messages, which could be a problem in applications where losing any kind of information was a high cost. But in the most recent versions of Kafka this problem has been solved, and currently, there are transactional shipping options.

In Kafka, the numbers are really impressive. Some benchmarks indicate that Kafka supports, without difficulty, over 100,000 messages per second for each node.

Another strong point of Kafka is the ability to integrate with various other tools like Apache Spark. Kafka has good documentation. However, Kafka does not have a wide range of supported programming languages.

For cases where performance needs to reach high levels, Kafka is more than a suitable option.

When it comes to Memcached, caching is one of the most known and mature markets. It has a key scheme/value storage for very efficient memory.

For the classic process of using cache, Memcached is simple and practical to use. The performance of Memcached is fully linked to the use of memory. If Memcached uses the disc to register any data, the performance is seriously compromised; moreover, Memcached does not have any record of disk capacity and always depends on third-party tools for this.

Redis can be practically considered as a new standard for the market when it comes to cache. Redis is effectively a database key/value, but because of stupendous performance, it has ended up being adopted as a caching tool.

The Redis documentation is very good and easy to understand; even a simple concept is equipped with many features such as pub/sub and queues.

Because of its convenience, flexibility, and internal working model, Redis has practically relegated all other caching systems to the condition of the legacy project.

Control of the Redis memory usage is very powerful. Most cache systems are very efficient to write and read data from memory, but not to purge the data and return memory to use. Redis again stands out in this respect, having good performance to return memory for use after purging data.

Unlike Memcached, Redis has native and extremely configurable persistence. Redis has two types of storage form, which are RDB and AOF.

The RDB model makes data persistent by using snapshots. This means that, within a configurable period of time, the information in memory is persisted on disk. The following is an example of a Redis configuration file using the RDB model of persistence:

save 60 1000stop-writes-on-bgsave-error nordbcompression yesdbfilename dump.rdb

The settings are simple and intuitive. First, we have to save the configuration itself:

save 60 1000

The preceding line indicates that Redis should do the snapshot to persist the data home for 60 seconds, if at least 1,000 keys are changed. Changing the line to something like:

   save 900 1

Is the same as saying to Redis persist a snapshot every 15 minutes, if at least one key is modified.

The second line of our sample configuration is as follows:

    stop-writes-on-bgsave-error no

It is telling Redis, even in case of error, to move on with the process and persistence attempts. The default value of this setting is yes, but if the development team decided to monitor the persistence of Redis the best option is no.

Usually, Redis compresses the data to be persisted to save disk usage; this setting is:

     rdbcompression yes 

But if the performance is critical, with respect to the cache, this value can be modified to no. But the amount of disk consumed by Redis will be much higher.

Finally, we have the filename which will be persisted data by Redis:

    dbfilename dump.rdb

This name is the default name in the configuration file but can be modified without major concerns.

The other model is the persistence of AOF. This model is safer with respect to keeping the recorded data. However, there is a higher cost performance for Redis. Under a configuration template for AOF:

appendonly noappendfsync everysec

The first line of this example presents the command appendonly. This command indicates whether the AOF persistence mode must be active or not.

In the second line of the sample configuration we have:

     appendfsync everysec

The policy appendfsync active fsync tells the operating system to perform persistence in the fastest possible disk and not to buffer. The appendfsync has three configuration modes—no, everysec, and always, as shown in the following:

You may be wondering why we are seeing this part of Redis persistence. The motivation is simple; we must know exactly what power we gain from the persistent cache and how we can apply it.

Some development teams are also using Redis as a message broker. The tool is very fast in this way, but definitely not the most appropriate for this task, due to the fact that there are no transactions in the delivery of messages. With so many, messages between microservices could be lost. The situation where Redis expertly performs its function is as a cache.

Let's look a little further at some very interesting tools to prove the performance of our endpoints. Local test endpoints help to anticipate performance issues that we would only see in production.

After sending the microservices to the production environment, some tools can be used to monitor the implementation of the performance as a whole. There are both free, as well as paid tools, and some very effective tools like New Relic and Datadog. Both are very simple to implement and have a dashboard rich in information:

The following screenshot represents the interface of DATADOG:

Obviously, there are options for performance monitoring that are totally free, as we have the traditional Graphite with Grafana and Prometheus. The free options require more settings than those mentioned previously to provide similar results.

From the free options, Prometheus deserves a special mention because of its wealth of information and practical implementation. Along with Graphite, Prometheus also integrates with Grafana for displaying graphics performance. The following screenshot represents the use of Prometheus:

This is a very important point because this is the last step in which a failure can be located without affecting the end user. One of the pillars of microservices architecture is processing automation. To build and deploy is no different.

The time to build is usually the last stage before moving the application to a particular environment, a quality environment, or stage production.

In microservices, all must have high coverage for unit testing, functional testing, and integration testing. It seems obvious to say, but many development teams do not end up paying too much attention to automated testing and suffer for it later.

To automate the application build process, and consequently, the application deployment, is fundamentally a good continuous integration tool or CI. In this respect, one of the most mature, complete, and efficient tools is Jenkins. Jenkins is a free and open source project. It is extremely configurable, being able to fully automate processes.

There are other options like Travis. Travis works online with a CI and is completely free for open source projects. Something interesting in Travis, is the great compatibility that it has with GitHub.

The most important factor of working with a CI is properly setting up the application testing process, because, as has been said before, this is the last stage to capture failures before affecting the end user of our product. The CI is the best place for the integration of microservices tests.

The strong characteristic of microservices architecture is the large number of components that can fail. Containers, databases, caches, and message brokers serve as examples of failure points.

Imagine the scenario where the application begins to fail, simply because the hard drive of a database is faulty in some physical component. The time of action in applications where there is no monitoring for this type of problem is usually high because normally the application and the development and support teams always start investigating failures on the software side. Only after confirming that the fault is not in the software do teams seek problems in physical components.

There are tools like pens-sentinel to provide more resilience to the pens, but not all the physical components have that kind of support.

A simple solution is to create a health check endpoint within each microservice. This endpoint is not only responsible for validating the microservice instance, whether it is running, but also all the components that the microservice is connected to. Tools like Nagios and Zabbix are also very useful for making aid work to health check endpoints.

In some cases, automated tests may not have been well written and do not cover all cases, or some external component, such as an API vendor, starts throwing errors in the application.

Often these errors are silent, and we only realize after a user reports the error. But questions remain as to how many users have experienced this error and not reported it. What value loss level mistake did the product have?

These questions have no answers and are almost impossible to quantify. To capture this kind of problem as quickly as possible all the time, we need to monitor the internal failures of the application.

For this type of monitoring, there are a number of tools, but the more prominent is Sentry. Sentry has very interesting features:

Sentry has a cost and unfortunately, there is no free option that is effective.

With the four fault points covered by warning systems, we are safe to continue with our development and put into production our microservices with the automated and continuous process.

Apache Benchmark is better known as AB, and that's what we'll call it.

AB runs from the command line and is very useful to prove the speed and response of endpoints.

Running a local performance test is very simple, as can be seen in the following example:

$ ab -c 100 -n 10000 http://localhost:5000/

The preceding command line invokes AB to run 10,000 requests (-n 10000), simulating 100 concurrent users (-c 100), and calling the local route in door 5,000 (http:// localhost: 5000/). The displayed result will be something like the following screenshot:

The result shows the server that performed the processing (Werzeug / 0.12.2), the hostname (localhost), the port (5000), and another set of information.

The most important data generated by AB is:

These three pieces of information at the end of the test process indicate the local application performance. As we can see in this case, the application used in this test returns 444.99 requests per second when you have 100 concurrent users and 10,000 charging requests.

Obviously, this is the most simple test scenario that can be done with AB. The tool has a number of other features, such as exporting graphics performance tests performed, and simulating all the verbs that the REST API can run on HTTPS certificates and simulate. These are only a few other attributes that AB offers as a resource.

Similar to AB, the WRK is also a tool executed by the command line and serves the same purpose as the AB. The following screenshot represents the WRK tool:

To run WRK is also very simple. Just use the following command:

    $ wrk -c 100 -d 10 -t 4 http://localhost:5000/

However, WRK has some different characteristics compared to AB. The preceding command means that WRK will run a performance test for ten seconds (d 10), with 100 concurrent users (c 100), and will request four threads from the operating system for this task (-t 4).

Quickly observing the command line, it can be perceived that there is no limitation or requests load statement to be executed; WRK does not work that way. The WRK test proposed is to perform load stress for a period of time.

Ten seconds after executing the command line that is a little higher, WRK will return the information, shown in the following screenshot:

Clearly, the returned data is more concise. But suffice to know that the behavior before a temporal change is made to our application.

Again, it is good to point out the local test feature and not necessarily the result of WRK is evidence that reflects the reality of an application in production. However, WRK offers good numbers to have a metric of application.

From the data generated by WRK, we can see that after the 10 seconds test with a 100 concurrent users and using four threads, our application in the local environment has the following numbers:

The WRK figures are somewhat lower than those provided by AB; this is clearly the result of the test performed by each type of tool.

WRK is very flexible for running tests, including accepting the use of scripts in the Lua programming language to perform some specific tasks.

WRK is one of my favorite tools for local performance tests. The type of test performed by WRK is very close to reality and offers numbers very close to actual results.

Out of the tools listed as an example for local metrics APIs, Locust has only one visual interface. Another interesting feature is the possibility to prove to multiple endpoints simultaneously.

The Locust's interface is very simple and easy to understand. You can tell how many concurrent users will soon be used in the interface data input. After the start of the process with Locust, the iron fist begins to show the GUI HTTP verb used, the path where the request was directed, the number of requests made during the test, and a series number for the metrics collected from multiple websites.

The GUI can be seen in detail in the following screenshot:

Using the Locust is very simple. The first step is the installation. Unlike AB and WRK, the installation of Locust is done through pypi, the Python installation package. Use the following command:

$ pip install locustio

After installation, you must create a configuration file called locustfile.py with the following contents:

# import all necessary modules to run the Locust:   
 from locust import HttpLocust, TaskSet, task 
 
    # create a class with TaskSet as inheritance 
    class WebsiteTasks(TaskSet): 
     
    # Create all the tasks that will be metrify using the @taks decorator  
    @task 
    # the name function will be the endpoint name in the Locust 
    def index(self): 
        # set to the client the application path with the HTTP
           verb        # in this case "get" 
        self.client.get("/") 
         
        @task 
        def about(self): 
          self.client.get("/about/") 
 
    # create a class setting the main task end the time wait for each request 
      class WebsiteUser(HttpLocust): 
       task_set = WebsiteTasks 
       min_wait = 5000 
       max_wait = 15000  

After the configuration file is created, it is time to run Locust. To do this, it is necessary to use the following command line:

$ locust -f locustfile.py

Locust will provide a URL to access the visual interface. Then the metrics can be verified.

Initially, Locust's configuration may seem more complex than the other applications shown in this section. However, after the initial process, the course of the test is very simple. As in AB and WRK, Locust has many features for deeper testing.