Distributed server solution for MMO projects (test results of the transport part)
At the request of readers, I provide a description of testing the transport part of the server solution on cloud technology, which I described in the last article. First, I want to describe a little what it is and why to test it. Having started my development with building server solutions for high-load MMO projects in real time, I gradually came to the conclusion that to maintain the maximum possible number of clients, it is necessary to use a fully distributed system. Below I give theses, on the basis of which, we are developing server solutions now.
The existing solutions use these principles only partially, and it is very problematic to build a truly cloud system based on them. Take at least the engine “BigWorld” in which a very interesting, in my opinion, system of dynamic, floating locations, which are tied to the objects of the system, is applied. What is suitable for huge seamless worlds with low rates of change. But as practice shows, it is badly combined with rapidly changing games in real time. We used earlier similar technology and abandoned it, making sure that for real scaling it is necessary:
')
And now, having finished, finally, the development of the main modules of the cloud system, we decided to test in action until one chain
Transport - Processing - Data.
Transport service
a) to connect customers
b) unpacking / packing commands
c) command forwarding
Work service
a) connecting logic modules (DLL)
b) transfer of commands to logic modules
c) command processing in logic modules
d) querying SQL and NoSQL
SQL service
a) receiving commands
b) SQL database query optimization
c) send replies
NoSQL service (objects)
a) object reading on request NoSQL
b) recording NoSQL objects
c) sending the result
At the beginning, the test client launches 1000 parallel connections to the server that are serviced by a dynamic thread pool. Then, after a random time interval, different for each client, a command is sent to the server. The server receives a command through the Transport service, unpacks it, recognizes and sends it for processing to the Work service. Work service sends the command to the correct logic module, where it is processed. A request is sent to the NoSQL database to get the desired object, its data is read and small calculations are made. Then the result is sent back to the transport server for shipment to the client. Queries in the SQL database are approximately ¼ of all requests from the client. So, as all data is stored in the operational database NoSQL, and SQL acts only as a data warehouse.
Computer Features:
OS - Windows 2008 server
RAM - 8GB
CPU - i7 (8 core)
SQL - MSSQL
All services were launched on 1 PC. To increase the load.
Test results for 1 service:
Simultaneous connections were made - from 5,000 to 10,000 individual clients (10 test programs of 1,000 clients each client asynchronously in a parallel thread)
NoSQL The number of processing requests for which the delay time does not exceed 1 ms - 1200 per second
SQL Number of processing requests for which the delay time does not exceed 1 ms - 500 per second
For the transport service (1 instance) the optimal number of connections is 10,000
According to the test results, you can see that the system works stably, without failures, only the processing time increases with increasing load. In reality, services will run on separate PCs (distributed system) and power balancers will ensure that the request delay time does not exceed 1 ms. This test is synthetic and does not guarantee that 10,000 full-fledged clients of a dynamic MMO game can be operated on one server. The technology is distributed and involves the creation of a computing cloud consisting of individual PCs connected to a local high-speed network. The system provides for vertical and horizontal scaling.
According to our calculations, about 10,000 real-time clients will need about 10 servers for an MMO game.
As the key point is the speed of calculating the logic of game objects.
VERY IMPORTANT! Make fast data processing logic. We have been looking for the optimal structure of logic for a long time and developed our model, which we called “Isolated calculation of game objects” . This model allows to avoid logical collisions and to simplify the calculation of logic for one object as much as possible. Using fully asynchronous programming and deferred procedures.
For those who are interested, “feel personally” after signing the NDA, we can provide test and admin clients
for your own tests.
Create, use distributed server solutions for your MMO projects - this will help in the future to avoid server side crashes. For all questions - please always help.
- Complete separation of the transport part of the project from the logical part and data
- Maximum modularity to create the optimal solution for a specific project
- Unification of solution services (any team can execute any of the services intended for this purpose)
- Asynchronous task execution
- SQL is intended only for persistent storage.
- Using NoSQL to store operational data
- Using a pooling system (reusable groups of objects)
- No data binding to processing services
The existing solutions use these principles only partially, and it is very problematic to build a truly cloud system based on them. Take at least the engine “BigWorld” in which a very interesting, in my opinion, system of dynamic, floating locations, which are tied to the objects of the system, is applied. What is suitable for huge seamless worlds with low rates of change. But as practice shows, it is badly combined with rapidly changing games in real time. We used earlier similar technology and abandoned it, making sure that for real scaling it is necessary:
- Complete separation of Logic, Transport and Data
- Unification of services of the same type (dynamic pools)
')
And now, having finished, finally, the development of the main modules of the cloud system, we decided to test in action until one chain
Transport - Processing - Data.
Transport service
a) to connect customers
b) unpacking / packing commands
c) command forwarding
Work service
a) connecting logic modules (DLL)
b) transfer of commands to logic modules
c) command processing in logic modules
d) querying SQL and NoSQL
SQL service
a) receiving commands
b) SQL database query optimization
c) send replies
NoSQL service (objects)
a) object reading on request NoSQL
b) recording NoSQL objects
c) sending the result
At the beginning, the test client launches 1000 parallel connections to the server that are serviced by a dynamic thread pool. Then, after a random time interval, different for each client, a command is sent to the server. The server receives a command through the Transport service, unpacks it, recognizes and sends it for processing to the Work service. Work service sends the command to the correct logic module, where it is processed. A request is sent to the NoSQL database to get the desired object, its data is read and small calculations are made. Then the result is sent back to the transport server for shipment to the client. Queries in the SQL database are approximately ¼ of all requests from the client. So, as all data is stored in the operational database NoSQL, and SQL acts only as a data warehouse.
Computer Features:
OS - Windows 2008 server
RAM - 8GB
CPU - i7 (8 core)
SQL - MSSQL
All services were launched on 1 PC. To increase the load.
Test results for 1 service:
Simultaneous connections were made - from 5,000 to 10,000 individual clients (10 test programs of 1,000 clients each client asynchronously in a parallel thread)
NoSQL The number of processing requests for which the delay time does not exceed 1 ms - 1200 per second
SQL Number of processing requests for which the delay time does not exceed 1 ms - 500 per second
For the transport service (1 instance) the optimal number of connections is 10,000
According to the test results, you can see that the system works stably, without failures, only the processing time increases with increasing load. In reality, services will run on separate PCs (distributed system) and power balancers will ensure that the request delay time does not exceed 1 ms. This test is synthetic and does not guarantee that 10,000 full-fledged clients of a dynamic MMO game can be operated on one server. The technology is distributed and involves the creation of a computing cloud consisting of individual PCs connected to a local high-speed network. The system provides for vertical and horizontal scaling.
According to our calculations, about 10,000 real-time clients will need about 10 servers for an MMO game.
- Transport: 1-2 servers
- Calculation: 3-5 servers
- NoSQL storage: 1-2 servers
- SQL storage: 1 server
As the key point is the speed of calculating the logic of game objects.
VERY IMPORTANT! Make fast data processing logic. We have been looking for the optimal structure of logic for a long time and developed our model, which we called “Isolated calculation of game objects” . This model allows to avoid logical collisions and to simplify the calculation of logic for one object as much as possible. Using fully asynchronous programming and deferred procedures.
For those who are interested, “feel personally” after signing the NDA, we can provide test and admin clients
for your own tests.
Create, use distributed server solutions for your MMO projects - this will help in the future to avoid server side crashes. For all questions - please always help.
Source: https://habr.com/ru/post/103340/
All Articles