task scheduling and thread affinity

[Jon Brisbin]

I'm able to do some load testing of an async app framework I'm building that's based on HawtDispatch. I'm noticing that the response times are not as consistent when compared to a node.js server I have running on the same box. I'm bouncing back and forth between the HawtDispatch-powered app and the node.js-powered app. In the fastest times, HawtDispatch outperforms node.js by a not insignificant margin. But those times are not as consistent as node.js' times are. I can only assume this is because of the context switching that's happening sometimes and not others.

Is there a way I can influence the decision of which thread to run a task on? In general, I'd prefer to always run a task on the same thread unless it's impossible to do so. By "impossible" I mean beyond some definable threshold of enqueued jobs, memory usage, or whatever is decided should be the metric (maybe make it extensible so a user can define what that algorithm is?). I feel like the current algorithm is a little too casual in its application of thread affinity.

In general, users of this framework will want more consistent response times, even if they're a tad slower, than really fast but highly variable response times. I don't want thread affinity at the cost of eventual thread starvation, so I absolutely want task migration from one thread to another. But I really only want that applied as a hail mary rather than the very loose thread affinity used now.

So the question really is: what tools do I have to influence HawtDispatch's performance/scalability characteristics w.r.t. task scheduling?

Thanks!

Jon Brisbin
http//jbrisbin.com

[Hiram Chirino]

Hi Jon,

If you want to try pinning a connection to a random thread queue try this:

DispatchQueue[] threadQueues =
Dispatch.getThreadQueues(DispatchPriority.DEFAULT)
DispatchQueue q = threadQueues[random.nextInt(threadQueues.length)

If you don't need to suspend/resume the q, you should be able to use
those queues directly just like a serial dispatch queue. If you do
need to suspend/resume then you should do a `connectionQ =
q.createQueue("connection:x")` type deal and use that instead.

The upside of using a pinned thread like that is that the NIO selector
worker is driven off the same thread which will further reduce cross
thread talk.

Regards,
Hiram

FuseSource
Web: http://fusesource.com/