TabiCan: Massive Multi- Agent System Reference: Architecture and Performance Evaluation of a Massive...
-
Upload
austin-casey -
Category
Documents
-
view
219 -
download
1
Transcript of TabiCan: Massive Multi- Agent System Reference: Architecture and Performance Evaluation of a Massive...
TabiCan: Massive Multi-Agent System
Reference: Architecture and Performance Evaluation of a Massive Multi-Agent System, G. Yamamoto and Y. Nakamura, Autonomous Agents ’99, Seattle
2001. 5. 31 Compiled by Rhee, Taik-heon
Contents
IntroductionTabiCanOverview of e-Marketplace MiddlewareAgent Scheduling MechanismPerformance EvaluationConclusion
Multi-Agent System
studied for many yearsvarious types of systems
e.g) distributed artificial intelligent system
singleproblem
small problem
small problem
small problem
solveproblem
Introduction
Agent Technology
Applied to e-commerce areaExamplesAuctionBots(http://auction.eecs.umich.edu)
uses agents that have user prefenceWebCompass(http://www.quaterdeck.com)
uses a search agent to obtain info. from WWW
Not Multi-agent System!
Introduction
TabiCan
Commercial service site providing airline tickets and package tours
Multi-agent system to obtain info. on internet different from DAI
independently developed agents interact with each other user and shops have their own agents on server
user agents obtains informationby interacting with all shop agents
Overview of TabiCan SystemTabiCan
WebBrowser
e-Marketplace A
e-Marketplace BShopAgent 2
ShopAgent 1
DirectoryService
ConsumerAgent
Matched with your request!Narita-Honolulu
Japanese AirLinesPrice = $900
Cheaper one!! Why don’t you buy?
Narita-HonoluluUnited AirLines
Price = $600E-Marketplace B is
another travel market.
ConsumerAgent Shop
Agent 3
We have a discount executive class ticket!
Narita-HonoluluNorth-West AirLines
Executive ClassPrice = $1200
Do you have..?Narita-Honolulu
Japanese AirLinesPrice <= $1000
Visit
Link
Role of Agents
Shop Agents live during server runs
Consumer Agents live for two days in serverremoved when lifetime is overmultiple access is available while
alive
TabiCan
History
1st phase(Dec. 1997): for single servers2nd phase(Aug. 1998): for multiple servers3rd phase(Dec. 1998): for multiple sites
TabiCan
Overview of e-Maketplace Middleware
Aglet System Development Kit(ASDK)(http://aglets.trl.ibm.co.jp)developed atIBM’s
Tokyo Research Lab.provides
mobile agent fn.and multi-agent fn.
Agent Interaction(1/2)
Sessiona sequence of message
viewed as state transitionstate
state-1: initialstate-2~99: intermediatestate-100: final
link indicate transition
Overview of Middleware
Agent Interaction(2/2)
Message Monitor registers all interaction protocolsdelivers all msg. to agentsverifies every msg.
if invalid, remove the messagewatch for processing of agent’s msg.
if time-out, terminate interactionand ask “AgentSchduler” to stop processing
Overview of Middleware
Agent Control(1/2)
In TabiCan, 2000 consumer agents were created in server30KB * 2000 = 60 MB memory is required!Each agent has a thread
If too many threads, system overload may occur
Control mechanism for memory and threads is the key issues for server!
Overview of Middleware
Agent Control(2/2)
AgentSchedulercontrol the amount of memory
by keeping agents in secondary storagecontrol the number of thread
by scheduling activities of agents
Overview of Middleware
Agent Scheduling Mechanism
Controlled by AgentScheduler
Memory ControlThread ControlScheduling Policy
Memory Control(1/3)
Swap-in and swap-out mechanismSimilar with OSDeactivation if the number of agnets exceeds limits,
some agents are stored as memory imagesin secondary storage
Activation if an agent needs to process a job,
the agent is read from storage
Agent Scheduling Mechanism
Memory Control(2/3)
Sequence of msg. delivery
Agent Scheduling Mechanism
State of agent execution State 1: processing a job State 2: waiting to move to another server
or to be removed State 3: not processing
but will soon receive msgs. State 4: not processing
and cannot predict next msg.Activation Priority state 1 > state 2 > state 3 > state 4
Deactivation Priority state 4 > state 3 > state 2
Agent Scheduling Mechanism
Memory Control(3/3)
Least Recently Usedalgorithm (LRU)
Thread Control
AgentScheduler queues requests for actions A thread fetch a request from the queue
Fetch priority Priority 1: in state 1, 2 and 3 Priority 2: in state 4 kept in main memory Priority 3: in state 4 kept in secondary storage Same priority: First Come First Served(FCFS)
Agent Scheduling Mechanism
Scheduling Policy(1/2)
boot.inispecifies the parameters for agentse.g: [CLASS_emplaceappl.tabican.Consumer]
indicates parameters needed by consumer agents whose class is “emplaceappl.tabican.Consumer”
Agent Scheduling Mechanism
Scheduling Policy(2/2)
schedule.confspecifies scheduling policiese.g: [CONSUMER]
limit # of consumer agents in memory is 200
limit # of threads for consumer agents is 10
Agent Scheduling Mechanism
Performance Evaluation
Desirable constant in relation to # of consumer agents inverse proportion to # of shop agents
Test 1: Single Server SystemTest 2: Two-Server System
Test 1: Single-Server System
Throughput of searches Turnaround time of searches Throughput of searchesagainst # of shops
Performance Evaluation
Test 2: Two-Server System
Throughput of searches
Performance Evaluation
Conclusion
A mechanism for controlling memory and CPU in multi-agent systems where thousands of agents interact on a single server is described.
Throughput is kept to a constantto an increase in # of consumer agents