API requests are slow? This time the backend is not to blame

question

During the development process, we found that the backend API requests were particularly slow, so we complained to the backend.

"Why is the API so slow? It takes more than ten seconds to request an interface."

Moreover, this situation occurs occasionally. Front-end developers said that it sometimes occurs, but it is not necessary.

However, after some operations, the backend colleagues found that there was no problem with the interface. They tried it through the postman tool and the test environment and found that there was no problem with the interface request speed.

“That feels like a front-end problem”?

Let's sort out the problem as follows:

• Backend API requests are particularly slow and occur sporadically.
• It did not recur in the test environment.
• The postman tool request did not reproduce.

Problem Solving Process

Where has the time gone?

The first question is, what is the API doing with all the time it spends?

We open the Chrome debugging tool and can see the time consumed by each interface in the network.

Hover over the Waterful of your time-consuming interface to see the specific time consumed by the interface.

It can be seen that the time consumed is mainly in Stalled, which means the waiting time from when the browser receives the instruction to issue the request to when the request can be issued. This is usually the time for proxy negotiation and waiting for the release of the reusable TCP connection, excluding the time for DNS query and TCP connection establishment.

So the API has been waiting for the browser to send it instructions. Taking the screenshot above as an example, it waited for 23.84 seconds. Its request and response time is very fast (only a few hundred milliseconds at most, which means that the interface mentioned by the backend is not slow).

So what exactly is the API waiting for the browser to do?

What is blocking the request?

After locating, we found that our project uses Server-Sent Events (SSE for short). Like WebSocket, it is the server that pushes information to the browser, but the difference is that it uses the HTTP protocol.

When not used over HTTP/2, SSE is subject to a maximum connection limit of 6. This limit is per browser+domain, so this means you can have 6 SSE connections open to www.example1.com, and 6 SSE connections open to www.example2.com across all tabs. This can be reproduced with the following demo.

Steps to replicate the issue:

• Visit http://ssebin.btubbs.com/multi/.
• Click Add Counter 6 or more times.
• Try opening another tab to the same address.

The result is that after the 6th time, the SSE request has not been responded to, and when a new tab is opened to the same address, the browser is also unable to access it.

The effect diagram is as follows:

The issue is marked as “unresolved” in Chrome[1] and Firefox[2].

As for the occasional occurrence, it is because front-end developers sometimes open multiple tabs with Chrome, and each tab has the same local development address, which will cause the maximum number of connections of SSE to be reached, and its execution time will be very long, which will block other requests and wait for SSE to complete.

So what is the solution?

Solution

Two simple and crude methods

• Don't open too many tabs. This way you won't reach its limit. (Because we only request one SSE per tab).
• In the development environment, turn off this feature.

Using HTTP/2

When using HTTP/2, the maximum number of HTTP connections at the same time is negotiated between the server and the client (the default is 100).

This explains why we have no problem in the test environment, because the test environment uses HTTP/2. In the development environment, we use HTTP 1.1, which will cause this problem.

So how do you use HTTP/2 in a development environment?

We are now in the development environment, and most of the time we use webpack-dev-server to start a local server and quickly develop applications. In the documentation, we find the server ^[3] option, which allows you to set the server and configuration items (default is 'http').

Just add this line of code.

 devServer : {
 + server : 'spdy' ,
 port : PORT ,
 }

Look at the effect, it was successful.

Principle: Use spdy[4] to provide services over HTTP/2 using a self-signed certificate. One thing to note is:

This option will be ignored in Node 15.0.0 and above, as spdy will not work properly in these versions. The dev server will be migrated once Express supports HTTP/2 built into Node.

Summary

I originally thought that this problem had nothing to do with the front end, but I didn't expect that it would end up happening to me. Improving the knowledge reserves of related skills and the way of thinking about problems may make it easier for us to locate such problems.

Make full use of the browser's debugging tools to think about a problem from multiple angles. For example, at first, I didn't expect that HTTP/2 could be enabled locally. Later, I accidentally searched for such a solution, and it turned out that there was one!

References

[1] Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=275955.

[2] Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=906896.

[3] server: https://webpack.docschina.org/configuration/dev-server/#devserverserver.

[4] spdy: https://www.npmjs.com/package/spdy.