a multiplayer game of parenting and civilization building
You are not logged in.
Pages: 1
Been keeping an eye on the server pop over the last week, checked today and we've got a 66/33% split on servers 1 & 2.
Is this because we have higher overall pop now or is there a breakaway group? lol
http://onehouronelife.com/reflector/ser … ion=report
Last edited by DJDisorder (2018-07-04 17:43:18)
Offline
that usually precedes a server shutdown, so no new players are born on server one, they are all redirected on server two untill one is empty.
if that's not the case then i don't know, maybe a big discord related action ?
I will be eve tana. If not an eve, my kids will be called numerically : Primo, Duo, Tertio, Quattro, Quintus, Sextus, Septimus, Octavius etc... ending with an -a if you're a girl.
Offline
Ah, knowledge! ty
Offline
No, I lowered the cap today after some people reported lag during peaks. Thus, load balancing kicks in earlier now.
I think 90+ players on one server is too much.
Offline
Ah nice, good to know.
Offline
No, I lowered the cap today after some people reported lag during peaks. Thus, load balancing kicks in earlier now.
I think 90+ players on one server is too much.
Do you have any performance traces? 100 people per server seems really low (~5 towns max).
Offline
Well, the server went through a bunch of optimization stuff a while back.
The main thing here is that, unlike other games, the contents of containers are visible at all times. So that information needs to be composed and sent to you as you walk around the map. A single map cell has one object ID in it. But if that cell contains containers or sub-containers, then there can be up to 17 IDs that need to be fetched from the database and sent to you. And that's just currently, with carts and baskets as the biggest sub-container combo. The map is sent to you in chunks of 32x30 tiles, or 960 tiles (960 database reads). But if that chunk contains a lot of containers, then worst case is 17x32x30, or 16,320 database reads.
There are many optimizations in place (only sending chunk slices if the new chunk overlaps with the old), and some caching. But the reality is that there can be a lot of information to fetch and send a player as they walk around the map. This uses CPU.
A lot of other games keep the contents of containers hidden until you ask about them (by opening the container and browsing).
The other thing that some games do is have the map be proc-genned client side instead of server side, so that the map doesn't really need to be sent to the client at all, except for where players have built stuff on it. Rust does this. I decided not to do that a while back.
There will be some additional optimization work done on the server in the future, but that's not my focus right now.
Offline
The map is sent to you in chunks of 32x30 tiles, or 960 tiles (960 database reads). But if that chunk contains a lot of containers, then worst case is 17x32x30, or 16,320 database reads.
You're getting just few bytes each time, but you're burning enourmous amount of CPU cycles to do that. KissDB does fseek+fread per query. Even if everything is cached in RAM, it'll cost you ~1k cycles * 16k = 16M cycles to do. I've proposed solution that will remove 99% of overhead in "Could ruins vanish slower" thread:
https://onehouronelife.com/forums/viewt … 015#p21015
Side effect of this optimization will be that you can safely keep ruins for around a year, instead of a week.
Offline
Pages: 1