Nights of poker and programming gambles (Push the queuing effects lower in the software stack...)


Got into a mental exhaustion state last night. Decided to go out to Starbucks with Shane instead of pushing at the code. As has become normal for him, he wanted to play poker.

We each won one game (that is, took all the chips in multiple hands). My win was rather fast, I just played fast, loose and high-stakes and chance delivered a victory. Shane's win was excruciatingly slow. I played fast and loose until I'd lost all save 20 chips but then switched to tight and conservative playing. It probably took him more than an hour to get those 20 chips (we don't raise the ante as we go). I had a natural 4-of-a-kind (i.e. I drew two fours and two fours showed up), a couple of flushes, and various other assorted unlikely hands. If I'd been dealing I'd have been a bit suspicious that I was cheating.

Anyway, we headed home around midnight, and having had a very large caffeinated beverage I was wired for sound. So, got some PyDispatcher hacking done that has been pending all week, then sat down and thought about how to make Cinemon scale up (I want to improve performance on current hardware by a factor of 3).

Which lead to a lot of false starts "I should use a shared-memory mechanism... how complex is that... hmm... alright, an RPC system... no, a dispatcher-routing system..." for half an hour. Then I realised that there was something simple I could do. I could spread out the queries across a large number of UDP ports and let the OS-level queues store incoming messages instead of having the Twisted-level code read the queue as fast as possible and generate delayed calls to deal with the results.

That's nowhere near a 3x speedup, but it does appear to have stabilised and improved web-site response times, which is almost as useful. A bit more hacking on that today to remove the processing-delaying code and see if that helps overall performance.

Comments

Comments are closed.

Pingbacks

Pingbacks are closed.