[Rhm-users] Re: [Rhemrg-users-list] RHM Performence

[Alan Conway]

On Wed, 2008-08-27 at 16:12 +0300, mark yoffe wrote:
> Hi
>  
> i have been using the system for some and have some quetions regarding
> performence
>  
> ----
>  1 
> -----
> i have used the PerfTest to benchmark the performance 
> and i receive results of around 70,000 transfers per second with the
> default values (message size 1024, 1 publish , 1 subscribe, etc..)
> with 1 Byte size messages i get around 160K transfers per second
>  
> than i used the request response example privded with the system and
> changed the message limit to be unlimited 
> and tested based on the example a transmission of 100,000 messages -
> the best time i got was 10 seconds for round trip time
>  
> so if i translate the numbers correctly 100K messages each way is 200K
> messages total 
> which is 20K per seconds not close 
>  
> which translates to around 20,000  
>  
>  
> can someone  please explain the differences between the numbers , is
> there something missing in the request response example to achieve hi
> performance results?
>  
> --
> 2
> ---
>  
> i have made another experiment using three RHMclients in an experiment
>  
> where one sends a message to the seconds and he second to the third ,
> than the third returns it to the first (1->2->3->1)
>  
> each one employs a similar technique to the request response server
> from the examples provided with the product
>  
> the results i receive show that the performance is slower than the
> request - response example
>  
> the change is not linear what took 10 seconds in the first test (point
> to point and back) now takes more than double the time 
> although only one more "communication step"  was added to the scheme
>  
> can someone please explain this behavior? is this correct? should the
> system behave like this?
>  

Not sure how you altered the examples but the request-response example
as it is coded has an important performance error: it first sends all
the messages from the main() thread, and then waits for all the
responses in the main() thread. So there is no interleaving of sending
and receiving. This is to avoid complicating the examples with threading
details.

Perftest on the other hand starts a separate thread for sending and
receiving, so send & receive are done in parallel. The other examples
have separate publish and subscribe clients so they can also be run in
parallel.

For any high-performance app you should be sending & receiving
asynchronously in parallel streams: either separate threads with
separate sessions or in separate processes.