Small improvements to game Cache

A large online (Web) game. I think there are two major impacts on the game performance.

 

1. Database reading affects the execution time of the game logic module code. Under Multi-concurrency conditions, the overall performance of the game is affected.

Reduce the impact. Data in the database can be read to the memory in advance. During Game Operation, memory data is read. In this way, the data bottleneck is bypassed to a certain extent. Generally, data like the mall is read into the memory. Because the sales data in the mall is generally relatively fixed. Easy to maintain.

This solution can be improved again. Player data can also be read into memory.

Whether to load all player data into the memory during game startup, or read and maintain the aging mechanism according to the distribution mode. In this regard, I have not taken the time to think and learn. If you have any friends who have high opinions in this regard, I hope you will give me some advice. Given that the market price of physical memory is not very expensive, this method of exchanging memory space for program performance is desirable.

2. network communication, after all, is an IO operation and a key factor affecting the game performance.

When talking about building a high-performance game, our colleagues occasionally talk about a solution to separate the chat module from another server. In this way, data communication is similar to high-frequency data communication. Compared to the underlying server performance, this is a big test. Generally, you may consider using C ++ instead of writing server code in Java. Compared with the underlying layer, C ++ has better performance than Java in this aspect.

However, no matter what language is used to write the server code. We always need to consider communication optimization.

From the first day of writing game code, I began to think about the Data Cache architecture of the front-end client. And implement the idea into the code. In terms of communication, we recommend that you do not need to communicate. If you can transmit a small amount of data, use a small amount of data as much as possible.

In this regard, we can optimize the game communication protocol, that is, the above mentioned "transfer a small amount of data, use a small amount of data as much as possible", which is another major aspect of the architecture. I will not discuss this with you today.

Another point can be optimized. The "Data Cache architecture" mentioned above. And implement the idea into the code. In terms of communication, we recommend that you do not need to communicate ". It is generally used for caching on the client side.

Today, I want to share with my friends a small solution for synchronizing Client Cache and server data.

If We cache all the data received by the client. For example, if player a views the list of all players, three data entries are displayed on page 1 (assume that there are 10 entries on page 1 ). If the content of this page is cached on the client. After the meeting, new Player B was registered into the game. Because a has 14 pages of memory cached and B players are added, although a is still on 14 pages, a cannot be refreshed. If a is used for registration, broadcast all players to update the cache. This approach is unwise. After all, it is not the mail data type. For such data. There are two solutions to the client cache.

First, the client needs to flip the page to 13 pages again. It will apply to the server and submit the version number of the current data page. The server decides not to send data to the client based on the comparison version number. However, it is cumbersome for the server to compare the version number. We have time to consider this solution.

Second, another method is relatively simple, that is, I will use it in the next period of time.

The client caches data by page. If player a just read 14 pages of data, it does not cache the data because there are only 3 entries and less than one page. Request data again on the next page. The server directly sends data without version comparison. If the data received by the client is full of the previous page, it will be cached and read next time.

The solution is simple, and the solution is also simple. Cache client data by page.

 

　　

Errors in this article can be better improved. Learning and making progress together.