Performance Basis of Common Interface Performance Pressing Test

background

With the service-oriented design of mainstream systems, especially the popularity of SOA architecture and micro-service architecture, interfaces have become the communication bridge between systems. Therefore, the performance of the interface is becoming more and more important.

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

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

The main target

Obtain single interface/single service capacity

Discover application performance bottlenecks

Discover database performance bottlenecks

The test strategy

An overview of the

In many cases, when designing the interface performance test script, we need to call the system interface platform. If the interface platform does not provide usable UI interface, then we need to write our own code to connect the interface platform with the test tool and call the interface according to the corresponding protocol. There are many dependent methods that need to be called during the operation of the interface method. Dependency on the content returned by different methods is also something to consider. But we have no control over the content of the interface. Sometimes the dependent module does not work properly, sometimes the dependent module is not fully developed, and sometimes we are objectively and unconditionally asking the dependent module to return the desired outliers. At this time, we need to Mock system implementation in the pressure test. After the Mock system (block) has defined the relevant data of the interface, fill in the target to return the result, so as to simulate the dependent interface to return the desired content

Combined with the open source performance testing tool JMeter (only discussed in this article), you only need to pass the URL through the simulation of concurrent HTTP requests to get the corresponding execution results, and then judge whether the interface execution is correct according to the returned results. Therefore, the time cost is relatively low and it is relatively easy to turn a scene into a test script. The parameters rarely change after the interface is published online. Because there are multiple callers when the interface is published as a service, all callers will be notified to modify the response if the parameters change, otherwise the callers will become unusable. Interface definitions are stable and do not change easily, so there is not much post-maintenance work associated with interface performance testing.

Main types of

type	The specific content
Efficiency (performance)	Concurrency, response time, TPS, error rate, resource utilization
The stability of	Repeated operation for a long time for a single user, concurrent operation for a long time for a multi-user, repeated operation for a long time under outliers, and maximum failure time
pressure	Treatment within specification under super specification load
restorative	Whether the system recovers normally after normal load

Common interface

The interfaces of mainstream systems can be roughly divided into HTTP interfaces and self-developed RPC (Remote Procedure Call) interfaces, although the HTTP interface is probably the more common.

HTTP interface

General pressure test Web system will contact the HTTP interface common HTTP and HTTPS two protocols

HTTP Hypertext Transfer Protocol, default port 80

HTTPS Secure Hypertext Transfer Protocol (HTTPS), which can be understood as the secure version of HTTP, is port 443

There are two common HTTP request methods: GET and POST

Two of the most commonly used methods for making requests/responses with the Server

GET requests data from the specified resource

The POST submits the data to be processed to the specified resource

The RPC interface

RPC (Remote Procedure Call Protocol) – Remote Procedure Call Protocol (RPC) is a Protocol that requests services from a Remote computer program over a network without the need to know the underlying network technology. Simply put, this means calling a server-side method implementation as if it were a native class method.

A little understanding of the STU and Skeleton concepts in RMI(Remote Method Invoke) is required. RMI’s proxy pattern passes methods to real objects through a proxy object. The Stub resides on the client and assumes the role of the proxy remote object implementer. The Skeleton class helps the remote object connect to the sttub to communicate.

Main components:

Main principles:

Entity objects and business interfaces are shared by clients and servers. Interface implementation is the functional implementation of the defined business interface by the server, and provides the interface instance in the registration service for the client to call.

The main RPC interfaces we’ve seen so far are Hession, Dubbo, HTTP, Thrift, Hprose, etc

Hession, Dubbo, Thrift, and Hprose are all implementations of remote method calls where the client needs to keep stubs to call the interface. This is why we need JMeter to reference the JAR package for our performance test.

Hession: is a lightweight remoting onHTTP tool that provides RMI functionality with a simple method, a kind of remote method call, using the binary RPC protocol (based on the HTTP protocol), suitable for sending binary data, not suitable for the transmission of complex object types.

Dubbo: Alibaba open source high performance excellent service framework, a remote method invocation framework. The Dubbo Registry is responsible for the registration and search of service addresses, which is equivalent to the service directory: the Dubbo Monitoring Center is responsible for counting the number and time of each service invocation

Thrift: A framework for interoperable and scalable services open to Facebook – a framework for remote method calls, development of services that are extensible and cross languages. 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 invocation developed by Chinese. It is an advanced lightweight cross – language cross – platform object – oriented high – performance remote dynamic communication middleware.

HTTP: Typically seen in Web applications, text is transferred over the HTTP protocol. When a URL sends a request, the server doGet or doPost method is called to get the corresponding parameters. When testing an HTTP interface, it is relatively simple to simply locate the URL interface and pass a parameter assertion.

The following is a brief description of the several interfaces:

If you copy the interface definition and its custom classes, try to keep the package name consistent with the development package. It is not recommended to copy the code directly because it is not easy to maintain. Instead, use Maven to import the interface and Hessian-dependent JAR package into the POM file. Usually with the help of HessianSpringFactoryBean, combined with JMeter custom Java class request and Stub access to the test tool for pressure test

HessianProxy is the core class of the Hessian Client to handle client requests. The proxy mode is adopted to represent the client’s calls to the remote interface. The timing diagram of the main program of the Hessian Client is as follows:

Dubbo interface pressure test:

If the service interface is obtained from the Dubbo registry, then the address of the Dubbo registry needs to be specified when setting up the test environment, and extending JMeter needs to configure the address of the Dubbo registry and the name of the interface that provides the service to the outside world. Direct connection requires JMeter to import the Dubbo framework-related JARs. The Jemter Dubbo plug-in is available and can be imported directly

Node description:

Provider: The service Provider that exposes the service

Consumer: A service Consumer that invokes a remote service

Registry: A Registry for service registration and discovery

Monitor: A monitoring center that counts service invocation times and service invocation times

Container: The service runs the Container

Jemter Dubbo plug-in address: https://github.com/dubbo/jmet…

Jemter DubboSample screenshots

Thrift interface stress test:

Write the interface in the Interface Description Language (IDL) via the Stub resident client call, generate the server Skeleton class and the client call proxy. The Skeleton class helps remote objects communicate with the STTUbb resident client connection. The client and server are tightly coupled together. You can’t change the interface on either side individually (not the implementation of the server-side code), and the data types passed by the server and the client are exactly matched

See the following article for details:

JMeter performance tool to test the Thrift RPC service

HProse interface pressure test:

The server realizes the function of the defined business interface, and provides the interface instance registration service for the client to call. Local functions and methods are published as services, and the client can either define the calling interface as needed or call the server-side functions or methods directly. Combined with JMeter custom Java class request and Stub access test tool for pressure test.

HTTP interface compression test:

It is relatively simple and can be asserted through JMeter HTTP Request SAMPEL concurrent invocation interface

In summary, the interface compression test method varies according to different frameworks, but in general, it involves the steps of acquiring the interface, concurrent requests, parameterizing data, executing scripts, asserting results, and monitoring data.

Let’s do two practical examples

Practical examples

First of all, Mock.

Here is a reference to the definition of mock from Taobao’s Interface Test White Paper:

Mock refers to the use of various technical means to simulate the required resources for testing purposes.

A resource that is mocked usually has the following characteristics:

The target under test depends on the resource

The resource may be unstable for a variety of reasons, return results may vary, or it may not always be available

The resource has nothing to do with the quality of the target being measured

These resources may be an external or underlying interface, a system, a set of data objects, or a working environment for a set of target software, etc. Mock can avoid the dependence on external real resources to realize the isolated test of the tested target, thus greatly reducing the difficulty of testing and saving the cost of testing.

It is important to note that there is, after all, a difference between a test that can be passed using a mock and a test that can be passed using a real environment. Sometimes we just need the system under test to be able to handle both normal and exceptional cases of dependency, and we can’t guarantee that our mocks can simulate every such case. So use mocks only when it’s really necessary.

Moco

Simply put, a MOCO is a mock-like tooling framework that is downloaded as a JAR package

You can find this on MoCo’s 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 over the HTTP protocol, such as Web services, REST, and so on, 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. Developing a WAR package and deploying it to any application server is notoriously tedious, even if we are using an embedded server. The WAR package also needs to be repackaged even if we only want to change it slightly.

To put it simply, MOCO is to solve the awkward situation that there is no backend support when developing the front end, and there is no dependency in place when developing the interface. Of course, MOCO’s flexibility allows it to be used in more and more scenarios, such as when we develop interface performance test scripts.

Features:

Only need a simple configuration of request, response and so on to meet the requirements, support HTTP, HTTPS, socket. Very flexible, so to speak.

Support setting Headers, Cookies, StatusCode, etc in request.

To GET, POST, PUT, DELETE and other requests are supported, very suitable for Web development.

There is no environment configuration, just a Java environment.

The configuration changes take effect immediately. You just need to maintain the interface, the contract.

All possible data formats are supported, such as JSON, TEXT, XML, FILE, etc.

It can also be integrated with other tools, such as JUnit, Maven, Gradle, etc.

Example foo. Json configuration:

[ { “response” : { “text” : “Hello, Moco” } }] 1. Load the configuration to start the MOCO HTTP Server

Java jar moco – runner — standalone. Jar HTTP – 12306 – c p foo json (1) making address: https://github.com/dreamhead/…

Test the HTTP GET method

The examples here set up only one thread

Startupget. json configuration file:

[{” description “:” this is a get request with cookies and parameters “, “request” : {” uri “:” 7 dget/”, “method” : “get”, “cookies” : {” login “:” 7 dgroup “}, “Queries” : {” name “:” zuozewei “, “sex” : “man”}}, “response” : {” text “:” success! “}}] 1. 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 that can access this cookie, and the native is localhost

For non-top-level domain names, such as second-level domain names or third-level domain names, the domain of the cookie set can only be top-level domain names or second-level domain names or third-level domain names themselves. Cookies of other second-level domain names cannot be set, otherwise the cookie 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 accepted by JMeter

Receive the return message to the server correctly

Test the HTTP POST method

Startupget. 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″ } } }] 1. Load the configuration to start the MOCO HTTP Server

Jmeter set headers

Jmeter set Cookies

JMeter sets the HTTP Post Request

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