I'm doing some testing and found an interesting performance tweak I thought I would pass along...
I have an 8 core opteron machine with a broker setup in which I have many producers feeding a single consumer, essentially a many to 1 scheme. When producing on the order of 2000msgs/sec, top showed cpu usage on the order of 12-18% for the broker. When running the broker under oprofile, I found that the heaviest hitters were very trivial functions like these: std::const_mem_fun_ref_t<bool, qpid::broker::DeliveryRecord>::operator()(qpid::broker::DeliveryRecord const&) const std::_List_iterator<qpid::broker::DeliveryRecord>::operator*() const qpid::broker::DeliveryRecord::isRedundant() const std::_List_iterator<qpid::broker::DeliveryRecord>::operator++() I assume the reason for that is with many threads on difference cpus writing to the same outbound queue, there is either lock contention or cache misses on those objects. Using the "--worker-threads" option to set the number of worker threads to 2 actually reduced my cpu consumption with this load to about a quarter of what it was using with the default settings. -Azim -- View this message in context: http://n2.nabble.com/Interesting-threading-behavior-tp4107583p4107583.html Sent from the Apache Qpid users mailing list archive at Nabble.com. --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
