“This is the 18th day of my participation in the August Gwen Challenge.

The background,

With the servitization design of mainstream systems, especially the popularity of SOA architecture and microservice architecture, interface has become the communication bridge between systems. Therefore, interface performance pressure measurement is becoming more and more important.

SOA(Server Orientation Architecture) is the current common component model. It links the different functional modules of a software system, called services, through interfaces. The interface can be a specific interface service or middleware that connects two modules to communicate. A large project is usually composed of multiple systems, each of which has a dedicated research and development team. The functions of a single system are called modules. The function of the module is divided by interface implementation and UI presentation of the background.

Microservices architecture is in some ways the next step in the continued evolution of service-oriented architecture SOA. Basically, this type of architecture is a special way to develop software, web, or mobile applications as a separate suite of services (also known as microservices). The creation of these services is limited to a specific business function, such as user management, user personas, e-commerce vehicles, search engines, social media logins, and so on. In addition, they are completely independent, which means they can write to different programming languages and use different databases. Centralized service management is almost nonexistent, and microservices communicate using lightweight HTTP, REST, or Thrift apis.

Ii. Main Objectives

  • Obtain single interface/single service capacity
  • Find performance bottlenecks in your application
  • Discover a database performance bottleneck

Test strategy

1, an overview of the

Most of the time, we need to call the system interface platform when designing the interface performance pressure test script. If the interface platform does not provide a usable UI interface, we need to write our own code to connect the interface platform with pressure test tools and call the interface according to the corresponding protocol. Interface methods need to invoke many dependent methods during execution. Depending on the method, the return content also needs to be considered. But depending on the interface content we can’t control. Sometimes the dependency module doesn’t work properly, sometimes the dependency module isn’t fully developed, and sometimes we objectively and unconditionally make the dependency module return the desired outlier. After the Mock system (baffle) defines the data related to the interface, the Mock system (baffle) can fill in the target result to simulate the interface to return the desired content

In combination with the open source performance testing tool JMeter (this article only focuses on this tool), the corresponding execution results can be obtained only by simulating THE URL through THE HTTP concurrent request, and then the interface execution can be judged according to the returned results. So the time cost is relatively low and it is relatively simple to convert a scenario into a test script. Parameters rarely change after an interface is published online. Because there are multiple callers after the interface is published as a service, if the parameter changes, all callers will be notified to modify the response, otherwise the caller will not be able to use it. The interface definition is stable and not prone to change, so there is not much maintenance work for the interface performance pressure test.

2. Main types

type The specific content
Efficiency (performance) Concurrency, response time, TPS, error rate, resource usage
The stability of Long time repeated operation for single user, long time concurrent operation for multi-user, long time repeated operation for outlier, maximum failure time
pressure Handling within specification under over specification load
restorative Check whether the system recovers after the load becomes normal

3. Common interfaces

At present, the interface of the mainstream system can be roughly divided into HTTP interface and self-developed RPC (Remote Procedure Call) interface, and HTTP interface may be more common.

3.1. HTTP Interface

HTTP interfaces are commonly used in pressure measurement WEB systems. There are two protocols: HTTP and HTTPS

  • HTTP Hypertext transfer protocol, default port 80
  • HTTPS secure hypertext transfer protocol, can be understood as the secure version of HTTP protocol, modeled after port 443

The two most commonly used HTTP request methods are GET and POST

  • GET requests data from the specified resource
  • POST submits data to be processed to the specified resource

3.2. RPC Interface

Remote Procedure Call Protocol (RPC) is a Protocol that requests services from Remote computer programs over the network without understanding the underlying network technology. In simple terms, this is to call the server-side method implementation as if it were calling a local class method.

You need to have some understanding of the concepts of STU (pile) and skeleton in RMI(Remote Method Invoke). RMI’s proxy mode passes methods to real objects through proxy objects. The Stub hosts the client and acts as a proxy for the remote object implementor. The Skeleton class helps remote objects communicate with stub connections.

Main elements:

Principle: Entity objects and business interfaces are shared by clients and servers. Interface realization is the function realization of the defined business interface by the server and provides the interface instance registration service for the client to call.

At present, RPC interfaces mainly include Hession, Dubbo, HTTP, Thrift, Hprose, etc

  • Hession, Dubbo, Thrift, and Hprose are all implementations of remote method invocation, where the client needs to keep stubs to invoke the interface. This is why we need the Jmeter reference JAR package for performance profiling.
  • Hession: is a lightweight remoting onhttp tool. It uses a simple method to provide RMI functions. It is a kind of remote method call and uses binary RPC protocol (based onhttp protocol).
  • Dubbo: Alibaba open source a high performance excellent service framework, a remote method call framework. The Dubbo registry is responsible for registering and searching service addresses, which are equivalent to service catalogs. The Dubbo monitoring center is responsible for counting the number and time of service invocation
  • Thrift: An open source facebook framework for interoperable and scalable services A framework for remote method calls, extensible and cross-language development of services. Allows you to define data types and service interfaces (IDL) in a simple definition file. The server skeleton is then generated and the client invokes the proxy
  • Hprose: An open source framework for remote method calls developed by Chinese. It is an advanced lightweight, cross-language, cross-platform, object-oriented, high-performance remote dynamic communication middleware.
  • HTTP: Commonly used in WEB applications, text transfer is based on HTTP. When a URL sends a request, the server’s doGet or doPost methods are called to get the parameters. It is relatively easy to test HTTP interfaces by locating URL interfaces and passing assertions.

Interfaces are described as follows: Hession Interface pressure test: Obtain the interface through the interface URL. If you copy the interface definition and custom classes, the package name should be the same as the development package. It is not recommended to directly copy the code, because it is not easy to maintain. It is usually obtained using HessianSpringFactoryBean, combined with Jmeter custom JAVA class requests and stubs into the test tool for compression

HessianProxy is the core class for Hessian client to process client requests. It adopts proxy mode and invokes the remote interface by the proxy client. The timing diagram of the main program of Hessian Client is as follows:

Dubbo interface pressure test:

If the service interface is obtained through the Dubbo registry, you need to specify the address of the Dubbo registry when setting up the test environment. You also need to configure the address of the Dubbo registry and the name of the interface that provides services externally when extending Jmeter. Direct connection to Jmeter requires importing JAR packages related to the Dubbo framework. The Jemter Dubbo plugin is now available and can be imported directly

Node description:

  • Provider: exposes the service Provider of the service
  • Consumer: Service Consumer that invokes the remote service
  • Registry: A Registry where services are registered and discovered
  • Monitor: monitors the number of service invocation times and service invocation time
  • Container: service running Container

Jemter Dubbo plugin: github.com/dubbo/jmete…

Jemter DubboSample screenshots

Thrift interface pressure test:

Write the interface (IDL) with Stub resident client invocation, generate the server skeleton class and client invocation proxy. The skeleton class helps remote objects communicate with Stub resident client connections. The client and server are tightly coupled. You can’t individually change the interface on either side (not the implementation of the server-side code), the data types passed by the server and client are exactly the same

The specific method can refer to the following article:

Performance tool Jmeter compacts Thrift RPC services

Hprose interface pressure measurement:

The defined business interface is realized by the server, and the interface instance registration service is provided to the client to call. The local functions and methods are published as services, and the client can define the calling interface according to its own needs, or call the server-side functions or methods directly. Then, j-script or custom Java request and Stub are used to access the test tool for pressure measurement.

HTTP interface pressure test:

The simplest is to invoke the interface assertion concurrently via Jmeter HTTP Request Sampel

In short, interface compression testing methods vary with different frameworks to implement request compression, but in general, they are all steps of acquiring interfaces, concurrent requests, parameterizing data, executing scripts, asserting results, and monitoring data.

So let’s do two practical examples

Four, practice small examples

First, what is a Mock?

Here is the definition of mock from Taobao.com’s Interface Test White Paper:

A mock is the use of various techniques to simulate various resources needed for testing. A mock resource typically has the following characteristics: Measured target depends on the resources, the resources may be unstable because of various reasons, changing or return results are not always able to access to the resources has nothing to do with quality of the measured target itself These resources may be an external or bottom interface, a system, a set of data object, or is a set of aimed software work environment. Mock can avoid the dependence on external real resources to achieve isolated testing of the tested target, thus greatly reducing the difficulty of testing and saving the cost of testing. It is important to note that there are differences between passing a test using a mock and passing a test using a real environment. Sometimes we just need the system we’re testing to be able to handle all sorts of dependencies, both normal and abnormal, and we can’t guarantee that our mock will simulate every one of them. So mock only when it’s really necessary.

4.1, Moco

Moco is basically a mock tool framework. Download it as a JAR package on Moco github.

Integration, especially based on HTTP protocol, e.g. web service, REST etc, is wildly used in most of our development.

In the old days, we just deployed another WAR to an application server, e.g. Jetty or Tomcat etc. As we all know, it’s so boring to develop a WAR and deploy it to any application server, even if we use an embeded server. And the WAR needs to be reassembled even if we just want to change a little bit.

Translation:

Integration, especially HTTP protocol based integration, such as Web services, REST, etc., is used extensively in most of our development.

In the past, we just deployed another WAR package to the application server, such as Jetty or Tomcat, etc. Developing a WAR package and deploying it to any application server is notoriously tedious, even if we’re using an embedded server. The WAR package also needs to be repackaged even if we just want to change it slightly. To put it simply, Moco is a solution to the awkward situation of developing front-end without back-end support and developing interface dependencies that are not in place. Of course, Moco’s flexibility allows it to be used in more and more scenarios, such as when we develop interface performance compression scripts.

Features:

  • You only need to configure request and Response, which support HTTP, HTTPS, and socket. It’s very flexible.
  • You can set Headers, Cookies, StatusCode, and so on in request.
  • Support for GET, POST, PUT, DELETE and other requests, suitable for Web development.
  • No environment configuration is required, just the Java environment.
  • The modification takes effect immediately. You just need to maintain the interface, the contract.
  • Support for all possible data formats, such as JSON, text, XML, file, etc.
  • It also integrates with other tools, such as Junit, Maven, Gradle, and more.

Foo. Json configuration example:

[{"response" :
      {
        "text" : "Hello, Moco"}}]Copy the code

Load the configuration to start the Moco HTTP Server

java -jar moco-runner-<version>-standalone.jar http -p 12306 -c foo.json
Copy the code

Github address: github.com/dreamhead/m…

4.2. Pressure the HTTP GET method

In each example, only one thread is set

Startupget. json configuration file:

[{"description":"This is a get request with cookies and parameters."."request": {"uri":"/7dget"."method":"get"."cookies": {"login":"7dgroup"
        },
      "queries": {"name":"zuozewei"."sex":"man"}},"response": {"text":"success！"}}]Copy the code

Load the configuration to start the Moco HTTP Server

Jmeter set Cookies

  • The name field is the name of a cookie.
  • The value field is the value of a cookie.
  • The domain field is the domain name from which this cookie can be accessed, and the localhost is localhost

For a non-top-level domain name, such as a second-level domain name or a third-level domain name, the domain of the cookie can only be a top-level domain name or a second-level domain name or a third-level domain name. Cookies of other second-level domain names cannot be set; otherwise, cookies cannot be generated.

Jmeter sets the HTTP GET Request

Note that the query string (name/value pair) is sent in the URL of the GET request: /7dget? name1=value1&name2=value2

Response result received by Jmeter

Correctly receive the return information to the server

4.3. Pressure the HTTP POST method

Startuppost. json configuration file:

[{"description":"This is a POST request with headers and cookies and Json parameters."."request": {"uri":"/7dpost"."method":"post"."headers": {"content-type":"application/json"
      },
      "cookies": {"login":"7dgroup"
      },
      "json": {"name":"zuozewei"."sex":"man"}},"response": {"status":200."json": {"name":"success"."code":"1"}}}]Copy the code

Load the configuration to start the Moco HTTP Server

Jmeter set headers

Jmeter set Cookies

Jmeter sets the HTTP POST Request

Note that the parameter is in JOSN format and is sent in the body of the message.

Response result received by Jmeter

According to our configuration, the server returns data in Json format

That brings us to the end of our two little practices

Source code:

  • Github.com/zuozewei/bl…