Server's temp files
From VbGORE Visual Basic Online RPG Engine
Although the client focuses quite a lot on high performance and low RAM usage, the server takes it to the extreme, doing every little thing possible to boost the performance as best as possible. One major boost to the server's performance is the usage of the temp files (found in \ServerData\_temp\ when the server is running). This article explains what these temp files are, and why they are there.
Contents |
[edit] Concept behind the temp files
There are three types of files that get stuck into this \_temp\ directory - map, object and NPC files. The temp map files are just converted versions of the .map files, while the temp object and NPC files are made by grabbing the information from the database. Each file ends with a .temp, and starts with either o (object), m (map) or n (NPC).
These files serve one purpose - loading speed. At runtime, every map, object and NPC has a .temp file made out of it, and from there on, the server only reads information on objects, NPCs and maps from these temp files (that is, when its not being read from RAM).
The format of these temp files is what makes them so great, not the information they contain. If you look at the UDTs for map blocks, you will see this line:
'*** IMPORTANT! *** ADDING ARRAYS TO THIS UDT WILL BREAK THE LOADING!
Or for the NPCs:
'THESE ARRAYS MUST STAY DOWN HERE AT THE BOTTOM OF THE UDT!
These are here because these temp files. The temp files work by loading the information from the database or .map file, then saving the UDT as a whole instead of the individual variables. This allows us to load it by making as few Get calls as possible. For example, this is how the map will load its information from a temp file:
Get #FileNum, , MapInfo(MapNum).Data()
Instead of setting to variables one at a time, or doing calculations to find out what the data is, its just loaded directly into memory in the exact format we want it. No conversions, no calculations. Normally, a 100x100 map could take about 300 milliseconds to load. As a .temp file, though, it can take as little as 1-2 milliseconds.
[edit] Advantages
As stated before, the primary advantage of this is speed. Combined with this, we do not have to read the objects and NPCs from the database more than once (at runtime). This keeps the database free for other operations, which is important for if you are using multiple servers or the database is accessed by your web server.
With this speed, memory loading / unloading becomes possible for maps with no players on them, the NPCs on those maps, and objects that haven't been accessed recently. Keeping the RAM clean is important since it will let you run the server on a machine with less RAM. If you are renting a server, the price per month will raise significantly as your RAM raises. You may be paying $30 a month for 256 MB RAM, but for 1024 MB RAM, you could be paying $60-$90 a month.
RAM cleaning is also important since it allows you to expand on your game without having to upgrade hardware. Because unused information unloads, the amount of objects you have does not matter. You can have 10 million objects, but if users are only using 1000 of them, only 1000 of them will be in memory. This allows you to design your game as you wish with less consequences.
[edit] Disadvantages
The most obvious disadvantage is disk space usage. Though, this is rarely going to be a problem. The typical map file is around 100 KB of disk space, 300 bytes for NPCs, and 125 bytes for objects. If you had a very low-end server that only had about 2 GB of disk space free, this will still require the following to fill it up: 21,000 maps, 7.16 million NPCs or 17.2 million objects. Of course, this doesn't count the disk space required to store these files, but still, most servers will give you at least 10 GB, often over 30 GB.
Now for a disadvantage that actually matters - complexity. The whole unloading / loading system is mostly fully automated, you shouldn't have to ever touch any of the code involving that. But the complexity part comes in with editing the UDTs. If you obey the highly obviously comments in the code on where you shouldn't put arrays, it shouldn't be a problem. If you don't even add arrays to these 3 UDTs, you shouldn't ever even have to deal with this complexity.
