Decay Alternatives

[Deantwo]

As far as we know, decay is a necessary evil to prevent server resources from going to waste on cities that aren't being used. But since the change to the Land claim system, decay of cities has felt really confusing.
I think we would all love it if decay didn't have to be a thing at all, since exploring and encountering other civilizations is one of the awesome things in this game. So without the full understanding about the reasons for decay, lets discuss alternatives.

If the number of cities is what is actually costing the most server issues, then I really don't know what can be done, aside from upgrading the server hardware. But storing information shouldn't be as big an issue if it isn't actually being used.

Assuming that it is the amount of computation it takes to handle the large amount of cities and units in them, maybe it would be possible to make the cities go dormant when their founder/owner/claimer hasn't been online for 7-30 days.

All manufacturing could either stop completely, slow down a lot, or be more selective; such as only working essential jobs.

Something similar to the old neglect mechanic could make the military units despawn and otherwise leave the military bases nonfunctional. And leaving the worlds defenseless against attacks in the process.

See also: (Idea thread) Automatically Add To Land

[Vectorus]

Something like Dean suggests would be a wonderful middle way. Neglected systems should be allowed to take up a certain amount of data storage, but next to zero processing resources. Storing the layout of the buildings, inventory and patents and the presence of spaceships, but ceasing to simulate production processes, citizen movements, anything dynamic sounds to me like a good solution.

Perhaps a certain chunk of storage that Haxus feels appropriate could be dedicated to neglected cities, and when it fills up the oldest ones just get deleted sequentially until there is space again.

[OnePercent]

I agree with this.

[Neils Iyssada]

I agree with it too.

[Rockinsince87]

I like that idea better too Dean. Have the city enter a freeze state after x amount of days, when someone shows up the star system is pulled out of stasis and restart the clock.

From a storage perspective, I don't see this being an issue either and you'll stop the wasted compute threads and excess SQL transactions from the servers but there is still another major issue.

Database bloat in general. The database would still have to search and index the information. After a while database queries would take longer and longer. Currently database systems will use their performance optimizers and cache the most used data in system memory for faster processing. That's fine and all but you then you'll require some serious RAM in your database servers. When I say serious I'm talking 512GB to TBs and on top of that the storage subsystems would need to be very fast.  

There still has to be some form of automated data retention expiration. Or a automated system moves systems that are in stasis to an archive database that only exists for this reason or you just increase the decay system to 90 days or something.

[Greydog]

I was thinking it could just be extended another two weeks. This is a good idea though, maybe a 3 tier system?

1- 30 day initial time period
2- 30 days in storage
3- decay begins if no action.

Two months seems fair to me.

[Rockinsince87]

I was thinking it could just be extended another two weeks. This is a good idea though, maybe a 3 tier system?

1- 30 day initial time period
2- 30 days in storage
3- decay begins if no action.

Two months seems fair to me.

Yeah that would work

[Vectorus]

I think if there is a dedicated space for "dormant" ruins on the server disk, there doesn't need to be a set storage time before deletion. It should just start deleting when it's full; then the effect is very predictable.

[Rockinsince87]

I think if there is a dedicated space for "dormant" ruins on the server disk, there doesn't need to be a set storage time before deletion. It should just start deleting when it's full; then the effect is very predictable.

Storage is not the issue in a raw sense. It's database size in general. Database engines use system memory to cache common query data and index information. It's possible that the database can outgrow the system resources, and that's not normally a bad thing in an enterprise environment. Once that happens you start hitting disk really really hard. That disk hit can be mitigated. It's all part of database sizing and design. 

Once it starts hitting your storage subsystems, if you have low IOPs and high disk latency, your in trouble. You can counteract this by using all flash storage in the form of SSDs or NVMe PCI cards. You still also have to make sure you don't have any bottlenecks in your Controllers/HBAs. SATA3 is slow and useless in all flash storage systems. SAS3 and above can handle flash storage systems. If you plan and implement those kind of solutions, the bloated database queries performance hits would be minimal if even noticeable at all. 

It really all depends on your situation though. If you purposely box your self into that situation, that's fine as long as you can front the capital to handle it. So if Haxus is not willing or unable to preform major storage subsystem upgrades, then he'll have to balance the database size and resource usage.

Basically, if you don't do the above. Buckle up and get ready for lag city.