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

This article focuses on "Flare application front and back performance optimization problem analysis", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn the "Flare application front and rear performance optimization problem analysis" bar!

Write at the front

Before I talk about flare, I want to talk about flame.

Flame is an online navigation page project on which you can store your commonly used bookmarks and online applications.

Flame default interface

After the trial, I thought the project was good, so I adjusted it a little to encapsulate a new image: https://github.com/soulteary/docker-flame

Application of new package

In the project documentation, I recorded my changes:

Simplify the program functions and dependencies (such as K8S), reduce the package size, reconstruct some detailed logic, and simplify the application startup process.

The weather acquisition logic is rewritten to use the city name instead of longitude and latitude to obtain weather data.

Some of the existing small BUG of the program have been repaired to support Chinese search.

The program is simply Sinicized.

But with further use, I found that the page has a bigger performance problem.

Because the Polish brother has adopted the SPA scheme, the project contains more than 6700 SVG icons and a number of web page fonts, and there are some minor problems in the interface, resulting in a very large page size and a large number of interface requests.

Even when you upload some SVG with more elements as your bookmark icon, the page rendering triggered by React will cause the browser to jam.

I have about a few hundred bookmarks to deal with, and I expect the number of bookmarks to grow in the future, so I used the program to create nearly a thousand bookmarks in bulk. Then I found that when rendering so many bookmarks, the page would get stuttered, and even searching for bookmarks containing keywords on the page would feel a significant frame drop.

So I decided to rewrite a lighter program to solve my needs.

In fact, the process of making flare is also a process of flame performance tuning. But before we can solve the problem, we must first be able to locate what the problem is.

Analysis of application performance problems

In fact, the performance optimization of this application is not complicated, and it is not different from the traditional application optimization: give priority to reduce the amount of computation, and use a more efficient way to solve the problem when it can not be reduced.

However, in terms of usage scenarios, you can start with functionality before analyzing technical problems.

Features that are not applicable to me

First of all, from a functional point of view, I do not need this application to integrate with Docker to provide "service discovery" functionality. For example, after I start the container, the application will automatically add the newly launched container as a bookmark or application.

Second, after having my own SSO service, I no longer need to use functions such as simple account password login, so this feature can also be removed.

Finally, with regard to the storage of bookmark data, I think that in the absence of a Web editor with a great user experience, it may not be as easy to manage and maintain as configuration claims. You can use any editor you like to update and maintain the content, and you can use Git or any way you like to save your own data in a white box.

Based on the above changes, I can probably write a few less parts of the code: container (Docker & K8S) integration, login authentication, applications and bookmarks, and "CRUD" for bookmark classification.

Problems in the front-end architecture

In the Flame project, the author uses projects created by create-react-app scaffolding, and the project relies on: React v17 + TypeScript + Redux. In order to provide concise and consistent icons, the author introduces Templarian/MaterialDesign-JS, a very simple SVG icon library with a very simple structure of DOM, in the front end.

After packaging using the build tool and server-side GZip compression, you need to transfer resources close to 1MB, and the original script is close to 3MB in size. The relatively large volume of the program results in a longer page load and execution time. For example, the first rendering time of a page fluctuates around 1s, in most cases, it will exceed 1s, and the completion time is generally more than 1.5s. It may be that the author is not familiar with server-side program development, although the interface will be reused in the front-end application configuration update, but up to 8 interfaces will be called when the content page is displayed. In addition, in order to display and update weather information on the page, Polish brothers also use WebSocket for data exchange.

Overview of Flame Application performance

Other problems have been mentioned earlier in the article, so I will not repeat them.

Problems in the back-end architecture

The technology stack used in the project is the latest version of the Node.js,Web framework for Express, which has a very high market share, while the ORM framework chooses Sequelize and the data storage is SQLite3. The above choice is not a big problem, and if the application does not need to provide browsing access publicly, there should not be any performance problems.

However, if we look closely at the service response, we will find that there are some requests that take a very long time to respond, such as page resources, such as JS program resources that are critical to the page, which consume close to 400ms for acquisition.

Flame network request record

In addition, the front end initiates multiple requests to obtain data, and uses SQLite in conjunction with data storage. If public content access is provided, it is easy to encounter performance bottlenecks.

Make improvements for the application

When we have a clear understanding of the above problems, for example, the easy solution is to restructure and adjust based on the original program, simplify the front-end request, reasonably split the module, deal with the loading and execution timing of resources, and adjust the way data is stored and processed. Improve the response of the server and other combinations. However, will this be the simplest and most profitable solution?

Adjust the front-end implementation

If we say that using MVVM framework in interactive page programs will have high benefits and cost performance, then in the lack of multi-end component code reuse, there is no server rendering requirements, using this kind of framework is a cost-effective choice.

Some students may ask, if you don't use frameworks like React, Vue, and Angular, will you pick up old tools like jQuery in 2022? Although it is possible, it is almost a pure display scenario, we can achieve business functions and simple interactions without JS, such as automatic focus, changes in the activation state of menu buttons, and even weather icons with animated effects.

So, when adjusting the implementation, there is actually another option: do not use any scripts.

Rendering efficiency of Flare script-free implementation

After completing the program, we can see that the complete time to get the whole page data, structure parsing, style calculation, element layout and page drawing from the server is in 33ms (including idle waiting time), in which the time consumption of key processes is less than 10ms, and the time to complete page rendering is reduced to 1.65ms.

After getting the fast rendering ability of the page, we can do the "no refresh" browsing of the page switch (because the rendering speed is fast enough), even if we don't use the browser to cache the resources and speed up the rendering.

Adjust the backend implementation

Although I like using Node.js very much and have shared three ways of optimizing Node.js code that you don't know in the past, in order to improve the response of high-performance resources at low cost, it is necessary to switch the technology stack here: such as Golang.

After using the simplified program function of Golang, the response of the program to each request can be maintained at the level of a few milliseconds (limited to network transmission), which is about 2-3 orders of magnitude lower than before. The critical DOM ContentLoad time of the page is reduced to 1/8.

Batch request status after Flare optimization

Combined with the rendering time mentioned in the front-end optimization above, the total rendering time from resource download to rendering is less than 10ms. If not for some restrictions of the browser, the rendering frame rate should be able to far exceed 60 frames, which further satisfies our realization that "even if refreshed, it is smoother than no implementation without refresh".

In the above implementation, I split the page icon request from the page document, which may not be the best solution in a scenario with a small number of bookmarks and a variety of icons, but once the number of bookmarks reaches hundreds or thousands, you will find that icon splitting can greatly improve performance.

Of course, in order to meet a relatively small number of scenarios, I have also implemented the merge output, including the website favicon acquisition, there are only two requests. When there are not many bookmarks, rendering performance is even better than document and resource split output.

Network requests in Flare request merge mode

Icon resource optimization

The solution used by Flame is to read the back-end interface configuration, dynamically create SVG icons from front-end scripts and insert them into documents, while the default way for Flare programs is to split SVG and documents to deal with page performance problems in the case of a large number of bookmarks.

Although the page performance problem has been solved, the server-side IO problem will come along, so we also need to deal with the release and read of resources on the server side, and try to change the disk IO of resources to zero.

It sounds mysterious, but in fact, combined with the way of code generation, it is quite easy to implement. Of course, because there is automatic GC in Go, a large amount of memory will be allocated when different resources are used, which will affect efficiency. Here, you can consider using persistence solution to solve the problem, which is interesting to deal with, but will not be expanded due to space and topic. There is a part that I mentioned in the last two articles about the use and optimization of Golang embedded resources.

Messing with Go Emed's records some time ago.

For example, without any optimization for the HTTP service implementation and limiting the running resources to the two cores, only after optimizing the resource IO, we can achieve a stable 3ms output resources and provide more than 27,000 responses per second.

Optimization of Container Image

In addition to conventional optimization, image optimization is also critical for applications in the container era. Container optimization, I have mentioned many times in the previous article, so no longer expand, you can flip through the previous content if you are interested.

# docker images | grep fla soulteary/flare 0.1.1 22b18ad73c66 12MBsoulteary/flaume 2.2.0 b39fffc0ca81 152MBpawelmalak/flame 2.2.0 fa47c93c0af6 179MBpawelmalak/flame 2.0.0 729b0fcea7f0 190MB

As you can see, compared with the original program, the size of the optimized program after local decompression is about 15 to 1/16 before.

Additional optimization

If we use lighthouse to test the Flame front-end implementation, we can see some minor problems in the front-end implementation. Although there are four green rings and three green ones, only one ring is green.

Flame App Lighthouse score

In the process of re-implementation, in addition to simplifying the structure and debugging the implementation, we also scored all four circles with full marks (Chrome version v97+).

At this point, I believe you have a deeper understanding of the "Flare application front and back-end performance optimization problem analysis", might as well come to the actual operation of it! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.