> The process size doesn't grow appreciably when receiving the data > frames. Which makes sense in that it's only dealing with a frame at a > time. > > The trace always hangs up the same way. It ping/pongs between > amqp_0_10::Connection::decode and SessionState::receiverRecord until > it gets to frame 79, at which point the delay kicks in. >
Ok, I found the limit that is affecting this: --staging-threshold N (5000000) Stages messages over N bytes to disk That explains my magic number. If I raise the threshold, I can send messages less than this size almost immediately. I also noticed that qpidd, despite me not passing in an explicit --load-module for the message store, still picks up my msgstore.so, so it is using that as the offload store. Removing that library makes the client work (my apologies earlier, I figured I had to pass it in explicitly.) That all being said -- 3 seconds a frame for the BDB persistence layer is underwhelming. Are there any performance tricks with using that module? Has there been any progress on a AIO implementation for flow-to-disk messages? Thanks, Joe --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
