 | Hi,
Great that you got further. The figures you now have would help you with the
decision process.
> THANKS Johnny, Olli, & Hans !!!
> The light shines in my horizon ... At last !!!
>
> I ran the example Johnny suggested:
> --------------------------------------------------------------
> --------------------
> Output of:
> TAO_ROOT\orbsvcs\tests\Notify\performance-tests\scripts\Max_Th
> roughput\2_Hops
> --------------------------------------------------------------
> --------------------
> # Throughput: 3232.12 (events/second) [48485 samples in 15.00 seconds]
> ## Latency: Avg = 3, Var^2 = 17025
> --------------------------------------------------------------
> --------------------
>
> Which is very similar to the result that Johnny got...
> so I could renew my hopes ... and humor :-)
>
> I noticed that this example didn't start the Notify_Service
> (at least it's not mentioned in the PerlScript, and it didn't
> showed up in the Task Manager). So I looked for a similar
> example that used the Notify_Service, and I ran the Notify
> one in the same "scripts\Max_Throughput" folder:
> --------------------------------------------------------------
> --------------------
> Output of:
> TAO_ROOT\orbsvcs\tests\Notify\performance-tests\scripts\Max_Th
> roughput\Notify
> --------------------------------------------------------------
> --------------------
> # Throughput: 1164.59 (events/second) [17470 samples in 15.00 seconds]
> ## Latency: Avg = 7, Var^2 = 46935
> --------------------------------------------------------------
> --------------------
>
> Which is dramatically BETTER than everything I had before.
> (I don't understand why using the Notify_Service.exe with
> exactly the same environment, drops the throughput to the
> half, but that's too refined for me by now...)
>
> So, I need to know why the
> "...Notify\performance-tests\Throughput" example at the
> beginning of this topic performs so bad, ... or why these
> other "scrips\Max_" examples perform so good :-) ?
>
> First of all: using de ORBVerbose option, I had found that in
> my executions of that "Throughput" example, all the activity
> in Client, Server, and NotifyService had regular stops for 5
> seconds periods (exactly 5 seconds... I was suspicious of
> some unknown network timeout ¿?). The problem is that the log
> lines at which those stops appeared where many and very
> different for me to figure out what was going on. I later
> reminded that the Throughput.cpp file used an
> ACE_Time_Value(5) in its Worker::svc() method...
> Either way, I then added the following line to the Notify
> Service's .conf (which I copied from the
> scripts\Max_Throughput\Notify\notify.conf file)
>
> dynamic TAO_Notify_Service Service_Object *
> TAO_CosNotification:_make_TAO_CosNotify_Service () ""
>
> And ran the Throughput example again. I noticed that the 5
> sec stops weren't there anymore. I don't know (yet) what does
> this line mean, but I looked at the results this time:
> --------------------------------------------------------------
> --------------------
> Output of the
> "TAO_ROOT\orbsvcs\tests\Notify\performance-tests\Throughput" Example
> --------------------------------------------------------------
> --------------------
> Default Resource Factory is disabled
> collocated_ec_ 0 ,burst_count_ 1, burst_pause_ 10000,
> burst_size_ 10, payload_size_ 48, consumer_count_ 3,
> supplier_count_ 1 expected count 10
> (1728)Waiting for shutdown signal in main..
> (2544)expected count reached
> (2544)expected count reached
> (2544)expected count reached
> (2144) (2544) Supplier done
> calling shutdown
> Waiting for threads to exit...
> (2144) (3092) done
> Consumer [00] latency :
> 13757.00[10]/23189.00/42974.00[1]/88132999.00 (min/avg/max/var^2)
> Consumer [00] throughput: 0.02 (events/second)
> Consumer [01] latency :
> 27836.00[4]/35937.00/62804.00[10]/100522352.00 (min/avg/max/var^2)
> Consumer [01] throughput: 0.02 (events/second)
> Consumer [02] latency :
> 41462.00[4]/49428.00/63969.00[10]/46633906.00 (min/avg/max/var^2)
> Consumer [02] throughput: 0.02 (events/second)
>
> Supplier [00] latency :
> 41986.00[4]/49990.00/64676.00[10]/47138099.00 (min/avg/max/var^2)
> Supplier [00] throughput: 0.02 (events/second)
>
> Totals:
> Notify_Consumer/totals latency :
> 13757.00[0]/36184.00/63969.00[0]/193211766.00 (min/avg/max/var^2)
> Notify_Consumer/totals throughput: 0.07 (events/second)
>
> Notify_Supplier/totals latency :
> 41986.00[0]/49990.00/64676.00[0]/47138099.00 (min/avg/max/var^2)
> Notify_Supplier/totals throughput: 0.02 (events/second)
> ending main...
> --------------------------------------------------------------
> --------------------
>
> Even when ALL the activity of the example took just 1 second
> in the NotifyService logs (1 Supplier delivering 1 burst of
> 10 events to 3 Consumers), the output results are much worse.
> I have to add that this test didn't work "out of the box", I
> had to comment the parse_args() call at the beginning of
> Throughput.cpp's main(). With that call, parse_args() was
> invoked twice and some of the params ended up with different
> values than those of the actual command line, with the effect
> of leaving the clients "waiting" indefinitely.
> I think that maybe something in this test is broken ¿?
>
> The other difference I've found between the
> "scripts\Max_Throughput" (that works fine) and the
> "Throughput" test that didn't work for me... are the lines at
> the Client and Server .conf files.
> What I mean is this:
> --------------------------------------------------------------
> --------------------
> ## supplier.conf,v 1.3 2003/07/06 21:41:58 pradeep Exp
> #
> # Note that this test is not portable because it does not use RTCORBA.
> # All priority values are for Linux
> #
>
> ##---- Load the Factories------
> dynamic TAO_Notify_Tests_Application_Command_Factory
> Service_Object *
> TAO_NotifyTests:_make_TAO_Notify_Tests_Application_Command_Fac
> tory () ""
>
> dynamic TAO_Notify_Tests_SupplierAdmin_Command_Factory
> Service_Object*
> TAO_NotifyTests:_make_TAO_Notify_Tests_SupplierAdmin_Command_F
> actory () ""
>
> dynamic TAO_Notify_Tests_Periodic_Supplier_Command_Factory
> Service_Object*
> TAO_NotifyTests:_make_TAO_Notify_Tests_Periodic_Supplier_Comma
> nd_Factory () ""
>
> ##------- Init the Application Object ----------
> static Command_Builder "Application -Init"
>
> ### --- Create Supplier connected to sa1 ----
> static Command_Builder "PeriodicSupplier -Create s_high
> -Direct c_high -EventType H -Priority 2 -Period 0 -Iter 50000
> -Load 0 -RunTime 15"
>
> ##--------- Run -------------
> static Command_Builder "Application -SignalPeer"
> static Command_Builder "Application -Run"
> static Command_Builder "Application -WaitForEvents"
> static Command_Builder "Application -DumpStats"
> static Command_Builder "Application -Shutdown"
> --------------------------------------------------------------
> --------------------
>
> My next step is to study the "dynamic" lines above... I guess
> that the static ones have more to do with the particular way
> in which this example is built (I mean using the
> Notify_Test_Driver exe). I think I should focus on the
> "dynamic" ones in order to find out what influences the way
> the Notification Service performs... Am I Right ?
>
> I have the last little question about Johnny's tip; when you
> run the line
> perl run_test.pl
> Are you using ActivePerl interpreter ? or the ACEPerl one?
> I don't understand much (or anything) about Perl, but in my
> path I only have ActiveState's perl, and I could run the .pl
> script you suggested. On the other hand I saw some PerlACE
> sentences in the script so I couldn't imagine how was that
> identifier treated (or known) by ActiveState's Perl interpreter...
We are using ActiveState Perl. ACEPerl/PerlACE is just a Perl library we use
to be able to easily write our test scripts.
> I have no words to expres my gratitude for all the help you
> gave me on this topic.
> Thanks again,
No problem. On the other questions above, I don't have much time at this
moment to help you out in detail without a support contract. See
www.theaceorb.nl for our services.
Regards,
Johnny Willemsen
Remedy IT
Leeghwaterstraat 25
2811 DT Reeuwijk
The Netherlands
www.theaceorb.nl / www.remedy.nl
|
|
