The current project team is developing a maternal and child product that integrates tools and community attributes. As of the publication of this article, there are close to 70 million registered users and over one million daily visits to the first screen interface. On the first screen, different data will be shown to the user, such as daily tasks, baby (baby) daily overview, prenatal music, sports videos, hot posts and other modules. The performance of the first screen interface will directly affect the app experience.
Our server-side RPC framework uses RESTful, and its bottom layer is implemented by curl. Curl uses the http protocol, and our server technology stack is PHP. We all know that compared with TCP, the http protocol not only has more http headers, but the performance of PHP itself is also a big problem. Without major refactoring, how to make the smallest modification and achieve the greatest performance improvement. Still very challenging.
For the first screen interface, we have completed two performance optimizations for it.
The content that originally belongs to one interface is returned in two requests separately. The first screen API returns key data, reducing the waiting time for the user to enter for the first time. On the second screen, return most of the remaining data. The division of the content returned by the specific API depends on the rendering order of the client. There is no absolute standard. But our principle is that the first screen API returns the least data as much as it can to avoid users waiting. The rest is left to the API of the second screen to complete. The difficulties of split-screen loading are as follows.
- Determine the data loading order, the most basic data must be returned first, and the client's students must also cooperate.
- The content of the first screen is closely related to the user's pregnancy status. How to control the refresh frequency of the API when the user switches the baby (switching to the baby has been born during pregnancy, and switching from baby A to baby B) Finally, for operability, a rougher approach is adopted, and the interface will be requested twice for each switch.
After the split-screen loading is completed, the waiting time for users to enter the homepage has been reduced from 2-3S to about 1S. It is not necessary to render the interface after the client gets all the content as before. Now you only need to get the interface of the first screen to complete the rendering of the interface.
Time-consuming for the first screen interface after split screen
The second screen interface takes time after split screen
Through the deployment of Xhprof performance analysis tools in the alpha and beta environments. We can see the performance loss of the actual API at the function level. The deployment method and usage method of the tool are not detailed here. With the help of Xhprof, we got the following conclusions.
- RPC uses the HTTP protocol, and a simple RPC call is close to the time-consuming of 10MS. The number of RPC calls on the first screen is close to 30.
- Within each RPC service layer, function calls can be used, and RPC methods are also used.
- Hotspot data is directly checked in the database, and the cache utilization is low.
- Data table indexes are used indiscriminately, and slow queries exist.
Combining the above points, in the actual operation process, from simple to difficult, gradually completed. The first can reduce RPC, so RPC requests can be reduced. The logic layer data is changed from the previous multiple acquisitions to one acquisition. Secondly, within the service layer, the non-breaking service layer does not use RPC, and directly requests it in the form of function calls. 3. the data that does not change in the hotspot is directly cached in the logic layer, and then thrown to the API for return. 4. track slow MYSQL queries and optimize query SQL. After completion, the performance of the first screen will increase by 30% to 50%. The second screen is increased by 40% to 60%. The actual results can be seen in the figure below