Shulou(Shulou.com)06/02 Report--

Baidu search: Xiaoqiang Test Brand

This article comes from the works of Xiaoqiang test brand students. You are welcome to contribute and look forward to your continued efforts.

Background

There is an interface http interface, GetPaymentURL, passing parameters is very simple, it is a sessionID (similar to the order number), this interface itself does not have anything, but it calls the interface of another module wallet, the wallet will eventually return a paymenturl and other information to the GetPayment interface.

In a word, GetPyamentURL is only responsible for passing parameters to the wallet interface. The main business logic is in the wallet. Finally, the wallet returns the result to GetPaymentURL. After getting the result, it does simple processing and returns the result.

Xiaoqiang comments: it is very important to understand the logic of an interface. In fact, I found that many people only pay attention to technology, but not business logic. As a result, many things that can be accomplished in one step have taken N steps, and the loss outweighs the gain.

problem

At that time, it was very slow to call the getpaymenturl interface (only one user called, 27 times in 100 times was more than 20 seconds, and the longest was more than 30 seconds). I am only a single user to make a request, how can it be so slow), but directly calling the wallet interface is very fast. And they are all tested 100 times with a single user under the same network, all of which are made requests in our company's intranet.

Xiaoqiang comments: I just want to say very good,

Analysis.

First of all, because the wallet interface is called directly, the response is normal. So I think the problem lies with getpaymenturl.

I used LR to analyze the results of getpaymenturl and found that buffer time is very long, further decomposition, server time is very slow, net time is normal. So I wonder if there is a problem with the server side of the GetPaymentURL interface itself, which leads to slow. But it doesn't make sense, ah, this interface is just a simple transmission, how can it be so slow and impossible? So I think it's better to keep the Internet.

Then I thought, wrong ah, why directly call the wallet interface, all normal, indicating that the network is normal. Later, after confirming with my colleagues, I later found that the direct call to the wallet interface is the public network (the test address developed to me is the public network), while the getpaymenturl should go through the direct connect. Although they all end up on the same server for processing, they go to different network nodes. So now I am more sure that there may be something wrong with the network + VPOS.

Xiaoqiang comments: the analysis logic is rigorous, can put and receive. Seize the different network paths to find a breakthrough

Here is another short story. At first, VPOS used a public network address, and then a colleague on our side configured a proxy, that is, no matter what public network address VPOS uses, it will be transferred by this agent, and eventually jump to a fixed address, and then transfer from this address to the wallet.

It is obviously not good to do this. First, for this kind of transaction involving money, it must be the address of the special line. But even if you go to the public network, why do you still go around in such a big circle, through what kind of agent you match, take a ride and go out again.

Immediately, I asked my colleague to change it to the address of the dedicated line pointing to the wallet, retested it, and everything turned out to be fine.

Although the result was a little surprised, it was neither the network nor the VPOS server, but was inexplicably caught in a circle, resulting in slow response time.

This is the result of 200 requests from a single user:

Xiaoqiang comments: why is the performance test fun? That is, you will find that sometimes you play with him, and sometimes he plays with you, just like why everyone likes to watch suspense reasoning movies, so patience, persistence and logical thinking are very important. However, here I suggest that the tools to be used to ensure consistency, after all, the statistical principles of each tool are different, if changed, it will cause some interference to the comparison of data. Here the student uses jmeter, while the above uses loadrunner.

Summary

1. Encounter this kind of interface is very slow, it is nothing more than the reason of the network + server side.

two。 In the case of such interface tuning (one interface itself encapsulates another interface), it can be further split. For example, directly call the interface of the wallet to see if it is normal. If he has a problem, he must first analyze the interface of the wallet. If there is nothing wrong with the wallet interface itself, it is necessary to analyze whether it is the interface of the getpaymenturl itself.

3. If you encounter problems, you should confirm with the relevant personnel.

Xiaoqiang comments: the summary here seems to be just a few words, but it reveals a message that I have been conveying, that is, to analyze problems to learn to split layer by layer! Only by breaking up the big ones into small ones can we slowly find a breakthrough. Many people think that it is difficult to analyze. In essence, there are two points: one is that the foundation is not solid enough, the second is that we will not split it, and we do not know how to disassemble it step by step.

If it helps you, retweet + like = support

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.