On Mar 6, 1:33 am, Adam Lee <[email protected]> wrote: > does my diagnosis of the problem seem right and, if so, any ideas for > the best way to deal with this? obviously adjusting timeouts would > probably only exacerbate the problem, so i toyed with the idea of > having a pool of clients (though i haven't really delved into the code > to see if that's feasible or would help at all) or possibly hacking it > to change how its i/o threads work. for now, we've just added a few > more machines to this cluster, but it seems like a waste of hardware > when i know that these things can operate above 90% cpu for a > sustained period with no problem.
It's possible that having multiple connections could help you. I haven't been able to exceed what I can do with one IO thread, but you clearly are. :) Building a pool of them sounds like a pretty easy way to deal with it and it's what I'd want to provide for a higher level of concurrency anyway. You could pretty much just use an array of clients and a random number generator (or ever-incrementing sequence number with proper rollover) and get the effect you want easily. If you're hitting 60% with one IO thread for 32 app threads, I'd expect two IO threads for 32 app threads to do quite well, but once you shift your access mechanism, finding the right number is pretty easy. Unfortunately, the one thing I got really wrong in my client was treating the front-end interface as an afterthought. That makes it harder to provide a good interface into something like this. There is a client interface, but it's named backwards.
