krishna rangaiah
2014-02-18 07:38:50 UTC
Hi Guys,
We have been experiencing some bottlenecks in the dispatch of messages
between agents in JADE. The context of the problem is as follows;
*Test Setup*
Given a pair of communicating agents (Agent A, Agent B), Agent A sends an
ACL message to Agent B which records the timestamp when it receives the
message. This is done to estimate the impact that variable ACL message size
in the range of {100KB, 200KB, .....5MB} has on the platform.
*Observation*
We have observed that when the ACL message size is <= 100KB, the message
manager is able to hold up just fine i.e. Even when the number of agents is
increased such that there are 'k' pairs of communicating agents in the
system that exchange messages <=100KB between them, the platform functions
normally.
However, when the message size is increased the platform begins to slow
down and at a size of >=300KB, the lag becomes too heavy and impacts all
the other agents in the system. i.e. If even one pair of communicating
agents exchange messages >=300KB, it is observed that remainder agents in
the system function with huge lags.
Some questions we have in this regard are:-
1. Is there any load balancing mechanism available at the message manager's
disposal to handle a scenario where message sizes increase?
2. Can we alter the specifications of the message manager and dispatch
mechanism while not having to override the MTP and use our own message
transfer protocol?
3. This behavior is a direct precursor to the queuing of an agent's inbox
and we believe that addressing this will also address the queuing problem
to a certain extent. We'd like to know your thoughts on this?
Thanks in advance for all your help,
Regards,
Krishna K
We have been experiencing some bottlenecks in the dispatch of messages
between agents in JADE. The context of the problem is as follows;
*Test Setup*
Given a pair of communicating agents (Agent A, Agent B), Agent A sends an
ACL message to Agent B which records the timestamp when it receives the
message. This is done to estimate the impact that variable ACL message size
in the range of {100KB, 200KB, .....5MB} has on the platform.
*Observation*
We have observed that when the ACL message size is <= 100KB, the message
manager is able to hold up just fine i.e. Even when the number of agents is
increased such that there are 'k' pairs of communicating agents in the
system that exchange messages <=100KB between them, the platform functions
normally.
However, when the message size is increased the platform begins to slow
down and at a size of >=300KB, the lag becomes too heavy and impacts all
the other agents in the system. i.e. If even one pair of communicating
agents exchange messages >=300KB, it is observed that remainder agents in
the system function with huge lags.
Some questions we have in this regard are:-
1. Is there any load balancing mechanism available at the message manager's
disposal to handle a scenario where message sizes increase?
2. Can we alter the specifications of the message manager and dispatch
mechanism while not having to override the MTP and use our own message
transfer protocol?
3. This behavior is a direct precursor to the queuing of an agent's inbox
and we believe that addressing this will also address the queuing problem
to a certain extent. We'd like to know your thoughts on this?
Thanks in advance for all your help,
Regards,
Krishna K
--
I am Only One, but still I am one; I cannot do everything, but still I can
do something; and because I cannot do everything, I will not Refuge to do
something that I CAN DO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://avalon.cselt.it/pipermail/jade-develop/attachments/20140218/4b854396/attachment.html>
I am Only One, but still I am one; I cannot do everything, but still I can
do something; and because I cannot do everything, I will not Refuge to do
something that I CAN DO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://avalon.cselt.it/pipermail/jade-develop/attachments/20140218/4b854396/attachment.html>