[Twisted-Python] Scalability of timers

[Tobias Oberstein]

> Just a final note.. a single no-fds call to select with a 0 timeout seems to take
> around 280ns on my Core 2. Presumably the better interfaces (e.g. epoll, but

Are you sure there is actually a context switch happening with this syscall using no FDs and timeout 0?

280ns means your machine can do 3.5 millions selects() per second. Mmh. I have a hard time believing this would sustain with timeout>0 and/or FDs - anywhere near that magnitude. 

http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html
 
> not poll) will also take around the same time.
> 
> It's really hard to write even a single Python function that gets anywhere below
> 1usec CPU time, and given how function-heavy Twisted is, I'd be surprised

PyPy:


import timeit
import time

def f1():
   pass

def f2(x = 3):
   return x*x

def f3():
   return map(lambda x: x^2, range(10))

for f in [f1, f2, f3]:
   for i in range(5):
      print f, timeit.timeit(f, number = 1000000)
      time.sleep(2)


oberstet at vbox-ubuntu1310:~/scm/scratchbox/python/twisted/timers$ ~/pypy-2.3-linux64/bin/pypy test2.py 
<function f1 at 0x00007f219ff0bd30> 0.00407981872559
<function f1 at 0x00007f219ff0bd30> 0.00138401985168
<function f1 at 0x00007f219ff0bd30> 0.00138092041016
<function f1 at 0x00007f219ff0bd30> 0.00148296356201
<function f1 at 0x00007f219ff0bd30> 0.00153708457947
<function f2 at 0x00007f219ff0bda8> 0.0269131660461
<function f2 at 0x00007f219ff0bda8> 0.0319480895996
<function f2 at 0x00007f219ff0bda8> 0.0243380069733
<function f2 at 0x00007f219ff0bda8> 0.0251939296722
<function f2 at 0x00007f219ff0bda8> 0.025454044342
<function f3 at 0x00007f219ff0be20> 0.474506855011
<function f3 at 0x00007f219ff0be20> 0.452003002167
<function f3 at 0x00007f219ff0be20> 0.446584939957
<function f3 at 0x00007f219ff0be20> 0.441245079041
<function f3 at 0x00007f219ff0be20> 0.467758893967


This is in a VM on low-end gear. My notebook actually.

With trivial functions like above, PyPy might even optimize away funs altogether and inline those. Not sure though.

> considerations like this factored usefully into a design at all :)
> 
> Adjusting timer coalescing to extreme settings might even worsen your app's
> performance, since it'll cause interpreter time and syscalls to all be
> compressed around the slack intervals, leaving the CPU idle more often, rather
> than running evenly spaced over time. This might produce less desirable app
> behavior overall (e.g. it has knock-on effects for network interface queues,
> bursts of disk IO/SQL queries, network switch buffer overruns, or whatever
> else).

I can see those points. Will keep in mind and measure.

However, I am running a multi-process server, so as long as those processes tick slightly pitched w.r.t. each other, and there are more processes than cores, I guess I can saturate the CPUs.

And then this is a network server, so there will be FD activity (lots of).

It's just that I want to limit the impacts of having massive amounts of timers associated with network connections (ping/pong to detect lost TCP).

In any case: thanks a lot for all your hints!

/Tobias

> 
> 
> David
> 
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python