Server operator handbook - VanaDev/Vana GitHub Wiki

Table of Contents Website Creating Accounts DB Maintenance Application Architecture Client Errors Performance Startup Debug MySQL MariaDB Release MySQL MariaDB Memory Debug Release CPU Network

There is currently no up to date software to run a Vana-compatible website.

Currently, accounts must be created directly in the database. Once this is done, Vana will take care of anything else.

Vana has a built-in system that automatically detects when DB schema changes occur and the programmer adding or changing the functionality is responsible for any migration queries needed. This means that you can upgrade the source code with confidence because it's all automatic.

Vana allows a great deal of flexibility in terms of where you deploy your code. It's designed so that if you would like, you can have 3 physical servers running 3 channels, 5 channels, 7 channels, or any number of them. You can run the LoginServer and WorldServer(s) on the same machine if you would like. You may have them on separate machines if you would like.

This distributed architecture allows you to scale in the way that you see fit. However, this does come at the cost of some complexity. It means that if you just want a simple server, you have to run at least 3 applications on your machine instead of having just one. This design differs from many emulators that emphasize creating a simple single application.

Please keep in mind that client errors for all versions write to the same place. So if you have players that are playing global and alternative servers at the same time, an error on your server may propagate up to the official servers and vice-versa. Your players may want to be aware that this type of activity can get them banned and that they should be very careful if they are mixing the two. Additionally, client errors will send call stacks which reveal the file locations and names.

As a preface to discussing performance, it should be clear that any discussion of performance is inherently complicated in modern software and on modern hardware.

I did some tests on my machine (Windows 7, Core i5 2500K) and these are the numbers I came up with. The Vana was essentially baseline, only a few accounts and a few characters.

All of the data (except map data) that the various servers use is loaded up-front.

 LoginServer started in 5.27 seconds.
 WorldServer started in 4.01 seconds.
 ChannelServer started in 20.4 seconds.

 LoginServer started in 1.22 seconds.
 WorldServer started in 0.021 seconds.
 ChannelServer started in 13.1 seconds.

 LoginServer started in 4.2 seconds.
 WorldServer started in 4.02 seconds.
 ChannelServer started in 8.29 seconds.

 LoginServer started in 0.219 seconds.
 WorldServer started in 0.017 seconds.
 ChannelServer started in 2.2 seconds.

 The full working set for LoginServer was 10,392K. Task Manager reported 3,436K.
 The full working set for WorldServer was 8,624K. Task Manager reported 2,088K.
 The baseline full working set for ChannelServer was 25,928K. Task Manager reported 16,796K.
 After loading all maps in .75, the full working set was 118,816K. Task Manager reported 108,740K.

 The full working set for LoginServer was 8,212K. Task Manager reported 2,656K.
 The full working set for WorldServer was 6,724K. Task Manager reported 1,992K.
 The baseline full working set for ChannelServer was 15,100K. Task Manager reported 9,816K.
 After loading all maps in .75, the full working set was 61,120K. Task Manager reported 55,560K.

Debug mode can be quite slow, especially when querying SQL. It is recommended to use Release mode. I have not yet found a way to effectively profile Release mode. Loading up every single map in .75 in Debug mode maxed out one core of my processor and caused some latency in responding to requests. Release mode was using a fairly consistent 0% of CPU.

Network performance is going to be generally pretty consistent with other emulators because they must emulate the same underlying protocol. However, Vana does have a unique inter-server communication mechanism. This increases memory usage relative to doing simple broadcasts between channels all the time, but saves a great deal on bandwidth. Since networking tends to be the bottleneck and memory consumption is very lean, we feel that this is a good tradeoff.