Re: [Quickfix-developers] sockets question: to block or not to block?

[James R. <jam...@gm...>]

Our experience has been good with regards to the
ThreadedSocketAcceptor. Currently we have an application that is
configured with ~300 sessions, of which usually ~200 are active at any
one time. Today, for example, ~10,000 orders and ~35,000 execution
reports have been processed by this app, with about 1 million FIX
messages passed among the sessions and the application in total. The
application has used about 20 minutes of cputime on a Linux box that
has four 2.4Ghz AMD Opteron's. This box is under heavy load via
database processes and user applications during market hours; the FIX
app doesn't show up as a cpu hog at all.

I should mention that our app does a couple of things which would
probably be frowned upon by others. For one, we use a MemoryStore
instead of a FileStore. We don't actually have a need for keeping the
MessageStore persistent, even intraday. Also, we use a ScreenLog
logger instead of a FileLog logger. These two modifications allow us
to support more sessions by keeping our usage of file descriptors to a
minimum.

Hope this helps,

-jr

On 6/16/06, Sean Kirkpatrick <sea...@pi...> wrote:
>
> In light of this information, I am considering spending the time to evaluate the ThreadedSocketAcceptor to prevent a single trouble-maker from affecting our other sessions.  I seem to recall there being some issues discussed previously on the list regarding the way the threads are attached / detached.  Does anyone have any positive or negative experiences they could share using the threaded acceptor?  Outstanding issues?  I would also like to know if there are any benchmarks in terms of # of sessions successfully supported and under what kind of load?
>