[Ace-users] Re: [tao-users] performance of COS Notification

Friedhelm Wolf friedhelm.wolf at googlemail.com
Tue Jul 24 08:20:46 CDT 2007


Hi Doug,

after having a look on the performance tests for the notification service, I
have
some specific questions about the Throughput performance test.

In general this test gives the following results:
for every consumer/ and supplier there is a throughput value in
events/seconds
and a latency stat with the minimum/mean/maximum values.

1. What does consumer latency mean? Is it the time
   between sending the message from the event channel and receiving it in
the
   PushConsumer?
2. The same for the Supplier: How can a supplier have a latency? It just
sends
    out events, right?
3. What is the unit of the latency values? Is it microseconds?
4. For every min/max latency value, there is a figure in [] brackets. What
does it mean?
5. What does the throughput actually mean here? Is it the number of events,
which can
   be sent per second? Does this mean, that I can simply evaluate the data
throughput,
   by multiplying the troughput value with the payload of a sent event (+
the header size or something)?
6. I did some measurements and found that even if the latency for 15
consumers is different for every
   consumer (basically it looks like that the calls are processed serially
and the last consumer has
   to wait the longest to get an answer) the throughput remains the same.
I'm not sure if
   I understand it the right way, but should a bad latency not result in
reduced throughput?

See the measurements I did below:

fwolf at simi122:~/SIMSAT/install/cots/ciao/ACE_wrappers/TAO/orbsvcs/tests/Notify/performance-tests/Throughput>
./Throughput -ORBInitRef NameService=iiop://localhost:9999/NameService
-consumers 15 -suppliers 1 -payload 4056 –burst_count 20

collocated_ec_ 0 ,
burst_count_ 20,
burst_pause_ 10000,
burst_size_  1000,
payload_size_ 4065,
consumer_count_ 15,
supplier_count_ 1

Consumer [00] latency   : 147[13149]/289/31184[2592] (min/avg/max)
Consumer [00] throughput: 410.21 (events/second)
Consumer [01] latency   : 246[1248]/453/53375[8677] (min/avg/max)
Consumer [01] throughput: 410.22 (events/second)
Consumer [02] latency   : 336[19726]/600/73159[8677] (min/avg/max)
Consumer [02] throughput: 410.22 (events/second)
Consumer [03] latency   : 428[19726]/737/93101[8677] (min/avg/max)
Consumer [03] throughput: 410.22 (events/second)
Consumer [04] latency   : 516[19726]/872/100888[13017] (min/avg/max)
Consumer [04] throughput: 410.22 (events/second)
Consumer [05] latency   : 604[19726]/1007/120831[13017] (min/avg/max)
Consumer [05] throughput: 410.22 (events/second)
Consumer [06] latency   : 703[19726]/1139/124101[13017] (min/avg/max)
Consumer [06] throughput: 410.22 (events/second)
Consumer [07] latency   : 794[19726]/1272/139108[13017] (min/avg/max)
Consumer [07] throughput: 410.22 (events/second)
Consumer [08] latency   : 882[19726]/1401/139386[13017] (min/avg/max)
Consumer [08] throughput: 410.22 (events/second)
Consumer [09] latency   : 974[19726]/1533/139535[13017] (min/avg/max)
Consumer [09] throughput: 410.22 (events/second)
Consumer [10] latency   : 1062[19726]/1665/139654[13017] (min/avg/max)
Consumer [10] throughput: 410.23 (events/second)
Consumer [11] latency   : 1150[19726]/1794/139833[13017] (min/avg/max)
Consumer [11] throughput: 410.23 (events/second)
Consumer [12] latency   : 1237[19726]/1924/139938[13017] (min/avg/max)
Consumer [12] throughput: 410.23 (events/second)
Consumer [13] latency   : 1325[19726]/2053/140051[13017] (min/avg/max)
Consumer [13] throughput: 410.23 (events/second)
Consumer [14] latency   : 1412[19726]/2183/140160[13017] (min/avg/max)
Consumer [14] throughput: 410.23 (events/second)

Supplier [00] latency   : 1534[14788]/2425/140278[13017] (min/avg/max)
Supplier [00] throughput: 410.17 (events/second)

Totals:
Notify_Consumer/totals latency   : 147[13149]/1261/140160[13017]
(min/avg/max)
Notify_Consumer/totals throughput: 6153.19 (events/second)

Notify_Supplier/totals latency   : 1534[14788]/2425/140278[13017]
(min/avg/max)
Notify_Supplier/totals throughput: 410.17 (events/second)
Any help from people, who have experience with this issues is very much
appreciated.

Thanks,
Friedhelm


On 7/16/07, Douglas C. Schmidt <schmidt at dre.vanderbilt.edu> wrote:
>
>
> Hi Friedhelm,
>
> > TAO VERSION : 1.5.8
> > ACE VERSION : 5.5.8
> >
> > HOST MACHINE and OPERATING SYSTEM:
> >     i686 pc, SUSE linux Enterprise Server 9, Kernel 2.6.5
> >
> > COMPILER NAME AND VERSION (AND PATCHLEVEL):
> >     gcc 3.3.3 (SuSE Linux)
> >
> > THE $ACE_ROOT/ace/config.h FILE:
> >     #include "config-linux.h"
> >
> > THE $ACE_ROOT/include/makeinclude
> > /platform_macros.GNU FILE :
> >     include $ACE_ROOT/include/makeinclude/platform- linux.GNU
> >
> > CONTENTS OF $ACE_ROOT/bin/MakeProjectCreator/config/default.features
> >     (used by MPC when you generate your own makefiles):
> >     N/A
> >
> > AREA/CLASS/EXAMPLE AFFECTED:
> >     COS Notification
> >
> > SYNOPSIS:
> >     performance benchmarks for COS Notification
> >
> > DESCRIPTION:
> > Hi there,
> >
> > we are considering COS (RT) Notification as a means to
> > exchange (a large amount of) asynchronous data.
> > I guess we are not the first ones out there doing this.
> > Are there any recent performance benchmarks or experiences from
> > projects, where the Notification service is used?
> >
> > We're especially interested in throughput and scalability
> > depending on the message size.
>
> Please see
>
> TAO_ROOT/orbsvcs/tests/Notify/performance-tests
>
> Thanks,
>
>         Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/ace-users/attachments/20070724/3cc79215/attachment.htm


More information about the Ace-users mailing list