Up to Main Index                          Up to Journal for November, 2012

                    JOURNAL FOR MONDAY 26TH NOVEMBER, 2012
______________________________________________________________________________

SUBJECT: Message(s) in a bottle(neck)
   DATE: Mon Nov 26 21:44:56 GMT 2012

Busy with work and busy with life but still I find a small amount of time to
work on WolfMUD :)

While working on the UID and Command changes I was also testing - just like a
good little programmer ;) - and noticed a weird performance issue. At first I
thought it was due to the BRL[1]. However upon further investigation it turned
out to be a network issue :s

Testing with 8192 bots the server was generating 15-17Mb/sec of network data -
server and bots all running locally. This is an interesting - if totally
unrealistic[2] - test. To start with I'm trying to spawn 8192 bots in only 3
starting locations - 2730 bots per location! In total there are currently only
41 locations so on average that's 200 bots per location once they all connect
and things settle down.

For all the bots to connect we generate about 3,725,085 messages per starting
location - 11,175,255 in total. Moving from one location to the next we
generate about 400 messages on average. If all the bots move one location each
we generate about 3,280,000 messages. There is also all the locking going on
as well. So having the network be the current Bottleneck isn't bad going in my
books!

My math may be a little quirky on the above but I think I'm right...

One thing I have noticed is that when there is a lot of contention for the BRL
the current scheduler picks then next goroutine to run randomly[3]. This means
you can grab the BRL, release it - because you need to relock, then quickly
lock it again. Meanwhile other waiting goroutines can wait for ages to get the
lock :( Looks like I might have to implement a FIFO queue for locking - easily
done using channels ;)

Just in case you are wondering, to get 8192 bots running around the server
uses about 15Mb^H^H^H^H 31Mb of memory currently[4].

--
Diddymus

  [1] Big Room Lock

  [2] Realistically if you have more than say 10 players in the same location
      all doing things messages would be zipping past so quickly you couldn't
      read them and the game would become unplayable.

  [3] I believe I read somewhere that this was a deliberate design decision so
      that developers didn't depend on specific behaviour for a specific
      implementation.

  [4] I edited this after some retesting and was going to use the Unicode
      combining long stroke overlay for the strike through text. However
      Firefox does not render this properly and puts the long stroke between
      the letters l-i-k-e- t-h-i-s- where as even Lynx, Chrome and IE8 get it
      right. Looks like a known font problem. See: https://bugzil.la/801410
      For reference here is the Unicode version: l̶i̶k̶e̶ ̶t̶h̶i̶s̶


  Up to Main Index                          Up to Journal for November, 2012