Configurable save locations

jdphenix

jdphenix

Member
Looking at the core code for handling serialization of world state, all the save locations are hard coded in the `/Saves` folder on the root of the install path.

It works, and nothing's wrong with it, but what do we think of being able to have your saves elsewhere. Maybe for performance considerations having the index files on one disk and the types and binary data on another disk?

I could probably implement this. As far as I can tell, it would require handling of save locations in backups, save, and load implementations.
 
You could probably do this pretty easily although I figure it would be easier to just stick the whole servuo folder on the fastest drive as it doesn't take up much space to begin with. Putting the index files on another disk won't help much because I believe the index just holds constructor types and not an actual index of of the binary file.
 
Maybe not another disk, but what if you put the saves on shared memory (/dev/shm)? There may be a huge improvement in load/save times by reading/writing directly to memory... maybe you could do the experiment and share the results with us :)
 
ppardalj said:
Maybe not another disk, but what if you put the saves on shared memory (/dev/shm)? There may be a huge improvement in load/save times by reading/writing directly to memory... maybe you could do the experiment and share the results with us :)
Click to expand...

A common strategy in management of SQL Server files is to have the log and database on two disks to avoid contention on bandwidth. My thought was the same.

A RAM cache is interesting, and if I do that would prefer to write it in a portable manner, so I'd need to research that. I'd also be concerned about durability (in the ACID sense), but it could be worth experimenting with. If it improved speed enough, perhaps it would be possible to save every 1 or 2 minutes.
 
ppardalj said:
Maybe not another disk, but what if you put the saves on shared memory (/dev/shm)? There may be a huge improvement in load/save times by reading/writing directly to memory... maybe you could do the experiment and share the results with us :)
Click to expand...

Ramdisk could be faster. It would be better to just use code to buffer the save in memory instead using multithreading. I have tried this on my server and saves are 10x faster from what I can tell. You can check it out at 192.151.158.220.
 
You must log in or register to reply here.

Active Shards

Donations

Total amount
$0.00
Goal
$1,000.00
View
Back