One Hour One Life Forums

In theory it can be done - with predicate locking and rollback+retry in case of confilicts.  In practice, I wouldn't go there - it's big ugly can of worms not worth the effort.

By prefetch I meant getting data from db into cache.  You already write-thru all data via cache, so stale data coming from pre-fetch can be discarded here.  Nothing a mutex or two couldn't handle.

Yeah, profiling this to track down real bottleneck is best action now.

Threading is often used on I/O bound code to have multiple requests issued in parallel.  So it frequently helps even with single core.  Looking at the server code, it wouldn't be a simple change, though.

"High-optimized" is a bold statement.  It's better than KissDB at the task at hand, but there is sill plenty of things than can be improved.  I would get rid of random access chains - long chains defeat the purpose of having hash in the first place.  To handle collisions I'd use plain linear probing - the data for next bin is most likely already in the disk cache anyway, so why to have random reads all over the place. If table load gets high or some chain is getting too long, just double the size of hash table.  You need to rehash all entries to do so, but there is a way do to it incrementally, so performance hit is negligible (in short: create table twice as large; new writes go into it; read checks first in new table then in old one; on each write copy/rehash also few elements from old table to new, making sure you don't overwrite new data with stale one).

There are even worse cases there (450+ ms):

 18  L4 | Tue Jul 17 01:08:11 2018 (515 ms)
  4  L4 | Tue Jul 17 01:08:11 2018 (519 ms)
 15  L4 | Tue Jul 17 01:08:11 2018 (534 ms)
 32  L4 | Tue Jul 17 01:08:11 2018 (566 ms)
 87  L4 | Tue Jul 17 01:08:11 2018 (653 ms)
458  L4 | Tue Jul 17 01:08:12 2018 (111 ms)
 68  L4 | Tue Jul 17 01:08:12 2018 (179 ms)
 18  L4 | Tue Jul 17 01:08:12 2018 (197 ms)
200  L4 | Tue Jul 17 01:08:12 2018 (397 ms)
 34  L4 | Tue Jul 17 01:08:12 2018 (431 ms)
 12  L4 | Tue Jul 17 01:08:12 2018 (443 ms)
--
 19  L4 | Tue Jul 17 01:08:13 2018 (944 ms)
 41  L4 | Tue Jul 17 01:08:13 2018 (985 ms)
 11  L4 | Tue Jul 17 01:08:13 2018 (996 ms)
224  L4 | Tue Jul 17 01:08:14 2018 (220 ms)
230  L4 | Tue Jul 17 01:08:14 2018 (450 ms)
445  L4 | Tue Jul 17 01:08:14 2018 (895 ms)
174  L4 | Tue Jul 17 01:08:15 2018 (69 ms)
 28  L4 | Tue Jul 17 01:08:15 2018 (97 ms)
 12  L4 | Tue Jul 17 01:08:15 2018 (109 ms)
 32  L4 | Tue Jul 17 01:08:15 2018 (141 ms)
  2  L4 | Tue Jul 17 01:08:15 2018 (143 ms)
--
 53  L4 | Tue Jul 17 01:08:25 2018 (888 ms)
  5  L4 | Tue Jul 17 01:08:25 2018 (893 ms)
 71  L4 | Tue Jul 17 01:08:25 2018 (964 ms)
 18  L4 | Tue Jul 17 01:08:25 2018 (982 ms)
270  L4 | Tue Jul 17 01:08:26 2018 (252 ms)
465  L4 | Tue Jul 17 01:08:26 2018 (717 ms)
184  L4 | Tue Jul 17 01:08:26 2018 (901 ms)
 43  L4 | Tue Jul 17 01:08:26 2018 (944 ms)
 16  L4 | Tue Jul 17 01:08:26 2018 (960 ms)
  2  L4 | Tue Jul 17 01:08:26 2018 (962 ms)
 60  L4 | Tue Jul 17 01:08:27 2018 (22 ms)
--
100  L4 | Tue Jul 17 01:08:54 2018 (547 ms)
 53  L4 | Tue Jul 17 01:08:54 2018 (600 ms)
 86  L4 | Tue Jul 17 01:08:54 2018 (686 ms)
  7  L4 | Tue Jul 17 01:08:54 2018 (693 ms)
205  L4 | Tue Jul 17 01:08:54 2018 (898 ms)
468  L4 | Tue Jul 17 01:08:55 2018 (366 ms)
 42  L4 | Tue Jul 17 01:08:55 2018 (408 ms)
 22  L4 | Tue Jul 17 01:08:55 2018 (430 ms)
 14  L4 | Tue Jul 17 01:08:55 2018 (444 ms)
 19  L4 | Tue Jul 17 01:08:55 2018 (463 ms)
 52  L4 | Tue Jul 17 01:08:55 2018 (515 ms)

And worst case latency seen by player can be combined latency from two successive runs (when his request came just shortly after you checked him on first run and is handled late during second run). So 270+465+RTT(150-200 for Europe) - thats nearly a second.

It's not unlucky moment.  You most likely just run head first into perfomance wall, where you can't handle player requests in real time and you lag behind more and more:

 11  L4 | Tue Jul 17 01:08:13 2018 (996 ms)
224  L4 | Tue Jul 17 01:08:14 2018 (220 ms)
230  L4 | Tue Jul 17 01:08:14 2018 (450 ms)
445  L4 | Tue Jul 17 01:08:14 2018 (895 ms)
174  L4 | Tue Jul 17 01:08:15 2018 (69 ms)
 28  L4 | Tue Jul 17 01:08:15 2018 (97 ms)

It does resolve itself only because lag for players becomes so bad, that they stop doing anything.

You probably also sending new map chunks to players that are moving.  That may require additional few hundred reads per player from time to time.  Looks likely that's the case here (handling move far away from birth spot took 100+ ms):

L4 | Tue Jul 17 01:07:51 2018 (510 ms) | general | Got client message from 991383: MOVE 235 -2 -1 1
L4 | Tue Jul 17 01:07:51 2018 (611 ms) | general | Got client message from 991375: MOVE 25 18 -1 0 -2 0 -3 0 -4 -1

There are lots of cases where handling move for player takes 20+ ms.  If that code would be running on client you would burn your whole time budget for a frame (50 fps).  So there is something very inefficient there.

So what's to do next?  I'd recommend to run profiler on the code and check those events where it takes 20+ ms to handle move.  Copy database, clear cache, play for a while with server under profiler.  See where you spend most of the wall clock time handling MOVE.

If profiling will be hard or you want to proceed blindly, I'd recommend following changes:

1. Get rid of long random access chains in db.  Linear probing with doubling the size of table when load gets high should work fine.  It will make it possible to run read request in parallel as a side effect (necessary for point 3).

2. Increase cache size.  Any reason you decided to have itty-bitty tiny cache for map data?  I'd give it half of the RAM.  Instead of 1-way, make it at least N-way or maybe even full LRU (disk reads are very expensive).

3. Run separate thread that will prefetch map data for players.  You send 32x30 tiles.  So prefetch thread should pre-cache map in all directions, something like 96x90.  When player does move in any direction, you should have tile and item data already in the RAM.  Special case Eve spawn to precache all data before she's born.

4. Expliot spatial locality of requests.  Instead of having multiple records per tile (biome, items, subitems, etc.), clump up all information about tiles and items in 8x8 or 16x16 block in one record.  For a some small write amplifictation, it would give you two-three orders of magnitude speed up on reading map data.

If you would prefer to work on game content instead of optimizations, I have some spare time right now.  So I'm open for short-term gig to work on it - just let me know if you're interested.

Asking meaningful questions letter at a time is quite a challenge

Can you elaborate why?  If you worry about noobs, they may be forced to finish tutorial first.

Marked Grave
[...]
numSlots=1
slotSize=1.000000

So I guess it can contain one small item, i.e. the same ones that you can put 3 of into basket.

It was already answered in this thread, before you asked question:
https://onehouronelife.com/forums/viewt … 266#p24266

Precogniton or what?

Please report it here:
https://onehouronelife.com/forums/viewtopic.php?id=2806

How does it work?  What counts as big town?  It's one per server or per player?

+1

+1

I think I've seen only end of it.   I've noticed because usually people propose with the live one...

I still think that a headless one is better choice for dower.  It won't run and you can still make a knife with it.  Great asset!

Great idea, but probably has to wait until trees grow on their own or we can plant them.  Currently it's non-renewable resource.

INB4: Global warming denial.