qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Interesting threading behavior
Date Fri, 04 Dec 2009 15:06:58 GMT
On 12/03/2009 12:54 PM, Azim Fatehi wrote:
>
> 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.
>
I think you're correct. That's consistent with what others have observed also 
and probably points to some good optimization opportunities.

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message