This is the 15th day of my participation in Gwen Challenge

Our system is based on vue-elementui-admin. Operators feedback that the online management system is seriously stuck and needs to be optimized after the number of users increases.

Caton phenomenon

After on-line testing, the catch was reproducible, but not stable.

The main manifestations of caton phenomenon are:

  1. Click the menu, the menu page Tagview loads slowly, you can see the slow loading bar at the top.
  2. After the page is opened, data loads slowly.

Train of thought

At a macro level, Caton is divided into two parts:

  1. Back-end interface latency: The main cause of caton 2.
  2. Front-end static resource loading is slow: The information is not clear and needs to be located.

The back-end interface card is faulty

There are two ways to locate faults on back-end interface cards. One is to record the response time of each interface through the back-end interceptor, and the other is to view the overall response time of each request through the front-end browser Network.

The following figure shows the back-end record format:

The following figure shows the response time of front-end viewing requests:

We found that the response time (waiting-TTFB) of some interfaces was very long, which really needed optimization. We optimized the back-end of these interfaces respectively.

Back-end optimization scheme:

Back end interface optimization can be achieved by optimizing execution statements, concurrency, Sql optimization, and caching, but I won’t mention that much.

Front-end resource load listener

Back-end interface delay can cause data to continue loading after the page is loaded, but theoretically it should not cause lag in initial page loading.

We think the main reason for the lag is in the front end.

Chrome-network monitoring found that Queueing and cost of some interfaces were very long but not very stable. Look it up.

View the timing breakdown of a request Timing Breakdown Phases explained in the Network Features Reference.

Here’s more information about each of the phases you may see in the Timing tab:

  • Queueing

. The browser queues requests when:

  • There are higher priority requests.

  • There are already six TCP connections open for this origin, which is the limit. Applies to HTTP/1.0 and HTTP/1.1 only.

  • The browser is briefly allocating space in the disk cache

  • Stalled. The request could be stalled for any of the reasons described in Queueing.

  • DNS Lookup. The browser is resolving the request’s IP address.

  • Initial connection. The browser is establishing a connection, including TCP handshakes/retries and negotiating an SSL.

  • Proxy negotiation. The browser is negotiating the request with a proxy server.

  • Request sent. The request is being sent.

  • ServiceWorker Preparation. The browser is starting up the service worker.

  • Request to ServiceWorker. The request is being sent to the service worker.

  • Waiting (TTFB). The browser is waiting for the first byte of a response. TTFB stands for Time To First Byte. This timing includes 1 round trip of latency and the time the server took to prepare the response.

  • Content Download. The browser is receiving the response.

  • Receiving Push. The browser is receiving data for this response via HTTP/2 Server Push.

  • Reading Push. The browser is reading the local data previously received.

We focused on Queueing, Stalled, Waiting (TTFB) and those that could be optimized. Translation:

Queueing

The browser will queue requests when:

  1. Request with higher priority.
  2. Six TCP connections have been opened for this source, which is the limit. Only applicable to HTTP/1.0 and HTTP/1.1.
  3. The browser briefly allocates space in the disk cache

例 句 : When any of Queueing occurs, the request will be eased

Waiting (TTFB) : Time spent Waiting for the initial response, also called first byte time. This time captures the latency of the server round trip and the time spent waiting for the server to send a response.

Distinction between Queueing and cost

例 句 : Originally a Queuing state that had departed, their differences were too significant (whether proxy/ SSL was used), their relationship was not and/or/parent/child It has been suggested to rename Queueing/defer /awaiting socket (see Chromium issue). [2]

Queueing

Optimization direction :(a server can have a maximum of six TCP connections at the same source/domain)

1. Reduce the number of requests. 2Copy the code

Stalled

Homologous link reuse could cause such a problem, because the links are available, and before the browser before you want to reuse the connection to save resources, with a socket to initiate connections before, after receiving the server returns the link has been reset/was not found, then find available from available link link, waiting for a long time, For details see Chrome-me-problem-resolve-process

例 句 : The time lag between a TCP connection being established and when data could actually be transmitted. After TCP three-way handshake, the sender sends data and cannot receive server ACK packets for a period of time (time varies for different operating systems), it resends them at a certain time interval (the time interval generally increases exponentially). The time from retransmission to correct response by the receiver is its own cost. If the number of retransmission times exceeds a certain threshold (5 times in Windows), the sender considers that the TCP connection is down and needs to re-establish the connection. A process by which a TCP connection is continued to transmit if it is successful and re-established if it fails So lengthy pockets of cost often result from lost packets, which also mean network or server problems.

Article [4] describes in detail the author’s localization of a long – delayed problem

One possible cause of prolonged delay is:

When I open a new label and try to access the same resource, this request will also read the cache. Assuming that the previous request was slow and took a long time, the subsequent request will be waiting because it cannot obtain permission to operate on the cache.

There are two solutions:

  1. The server sets the Response headerCache-Control: no-cache. That is, no cache.
  2. Adding time stamps to requests makes each request unique.

Waiting (TTFB)

It is recommended to keep this value below 200 ms [3]. Long TTFB will reveal two main problems:

  1. The network condition between the client and server is poor.
  2. The server application responds slowly

DNS Lookup

DNS query time

  • Optimizable part
    • Don’t have too many new domain names (possibly recursively queried around the globe) to refer toDomain of convergence.
    • To reduceDNSParse paths (if there are many internallyDNSServer resolution).

Optimize the summary

Main optimization direction

  1. Reduce the number of requests + domain name divergence to solve the Queueing problem
  2. Disable caching, or request timestamps to resolve cost – hour issues
  3. Optimize the server response (see the above back-end optimization method) to solve the TTFB duration problem

Follow-up optimization direction needs to learn the specific Chrome request analysis to do. See [4] and Chrome’s official website.

[1] Understand resource loading timing

[2] Network Resource Timing Timing

[3] Chrome DevTools’s Queueing and cost – based analysis

[4] Tracing the slow loading of pending pages