The applicability of Ajax and its impact on server performance

Ajax has been hot for two or three years. It has brought revolutionary changes to the web and unprecedented experience to users. Although Ajax will bring many benefits to Web applications, you still need to carefully consider where Ajax applications are used and how they are used. Do not abuse them.

First, I will discuss several old problems:

The first old problem is that AJAX requires support for javascrip and XMLHTTP objects, so browser compatibility needs to be considered. Fortunately, most browsers on the market already support XMLHTTP and JavaScript. Currently, we can minimize the compatibility issue, but it does not mean that we can ignore it. After all, different browser workers execute the same client code to produce different results.

Second, users' habits. Many users get used to interacting with servers in traditional ways. Although they may be tired of it, they get used to it, when a new method suddenly appears, it will make them wrong. Ajax does not need to refresh the browser. Therefore, in many cases, users may feel confused when performing an operation, especially when the network speed is slow, it takes a long time for a user to respond to a request. during the waiting period, the user may think that the Web browser has a problem or do something else. In addition, users will get used to some of the functions provided by browsers, such as forward, backward, refresh, and stop. These functions are frequently used and used by users, when Ajax is used, many of these functions will become invalid. Of course, many people have written solutions and there are many articles on these solutions.

In addition, you need to pay attention to the impact on the server performance.

Ajax asynchronous requests. This method brings about a new problem. In the traditional mode, each request sent to the server by a user needs to wait for the server to respond before another request can be made to the server, in this way, subsequent requests can be processed after the previous request is executed. However, Ajax breaks this constraint and allows a user to execute multiple requests continuously. Compared with the traditional method, this puts higher requirements on servers and brings greater challenges to program designers. In general, we should avoid this situation as much as possible. For example, for Sina's comment page, the drag bar by PAGE adopts the asynchronous request method, users can easily drag the cursor to the desired page, but during the drag process, each page point of the cursor will request the corresponding data to the server, if you drag the cursor to the 10th page at a specific speed, the server will have 9 requests redundant, if the nine redundant requests allow the server to read the database, this will waste a lot of server resources. If the user finds that there are no things he wants on page 1, and then moves to page 2, the server will request the corresponding data, but in fact the server has obtained the same data, if such a thing happens in real life, you may feel that it is a waste of resources.

OK, take paging as an example. If we do not need to drag a bar, we will follow the previous paging idea to "get and need". Each request for different pages will only retrieve the data of this page, and use ajax to give users a better experience. This seems reasonable, because we used to do this, but in fact it is not the most reasonable method. Generally, users prefer to view the first three pages, which are most likely to be repeatedly requested. In the traditional mode, because the server will be sent back to the server for processing in any case, the "income and need" statement is put forward in the paging concept. However, it would be a little rigid to use this method when using Ajax. Since Ajax is used, it is very certain that your user needs to support Javascript. Why not paging it on the client? As mentioned above, for the first three pages that users like most, if users need to read 1st pages from 3rd pages, and if they are "income and need", Ajax is useless, the user needs to request the server three times when reading the 3rd page.

Let's compare the two cases (assuming there are no pages of 10 Data Records ):

1. Generate 3 Requests + open 3 databases + 10 data records read and transferred each time
2. Generate 1 request + open 1 Database + read 30 data records each time and send

Case 2: Open the database twice less than Case 1, and execute two database queries on it. There are two fewer requests and 20 more rows of query data.

Obviously, in 2nd of this process, the user will wait for less time and the server will do less processing.

This is my new paging method. One-time reading of the data that the user will request multiple times is performed on the client. The user obtains more data during the first request and then processes the data through the client. In this way, the user does not need to request the server when reading the 1st page from page 3rd, switching the first three pages will become more convenient and reduce the burden on the server. The only downside is that the user will wait a little longer for the first request, but the query and transfer of more than 20 pieces of data is insignificant compared to the time saved by PAGE switching, in addition, don't forget Ajax. using it, we can make users feel that the amount of 20 more pieces of data is insufficient.

AJAX can bring a good user experience to users, but poor processing will lead to a greater burden on the server. If it is also well processed, it can reduce the extra burden on the server, the specific situation depends on how to use it.