Papers in PDF format

The Aria.recorder is also capable of spawning completely new “virtual” Aria.recorders
that each answer on different communication ports. This is very useful to administrators
that may be hosting multiple websites and need to guarantee access bandwidth to each site
as well as manage the activity accounting information from one site separately from that of
another site.
Aria.recorder may run as a single process, but the number of threads used by the engine
are user configurable and can be changed dynamically. It can support hundreds of threads
which are only limited by the memory and swap space of the specific hardware in place.
There are six basic classes of threads:
• Accept
• Buffer
• Update
• Transaction
• Scheduler
• Reaper
Web administrators can allocate the maximum number of threads to each class, depending
on specific hardware limitations to optimize system resources.
The Accept thread grabs the data streaming from the Aria.monitor and throws the data
onto a connection stack. The Buffer thread then grabs the data from the connection stack
and places it into a buffer stack, releasing the Accept thread. The Buffer stack can expand
in memory to accommodate peak loads, so the data can be processed later as more system
resources become available during off-peak hours. If Andromedia’s Aria.reporter is
creating real-time reports, then additional hardware can be added at the site to minimize
buffering and accommodate the immediate processing of all captured data. (A future
Release will call an API to read the latest updates.)
The Transaction thread parses the buffered data through a series of functions that are
extensible based on specific site and/or application needs. The unique architecture of this
extensible thread provides tremendous flexibility for configuring Aria.recorder. The
functions used by this thread are customizable for specific site and/or application needs,
and can be easily modified as requirements change over time. All real-time data needs are
controlled by this thread. Data elements that have been tagged for real-time access are fed
directly into memory and made immediately available to the application counting on it.
The Scheduler thread is used as a filter to purge information on a periodic basis. It is
used for sampling purposes and for creating reports based on persistent data that has been
previously captured. The Reaper thread is used for aging the data and clearing disk space
by deleting obsolete data based on user specified rules. Aggregate information on the
______________________________________________________________________________
The Aria Architecture Page 18 Andromedia, Inc.
White Paper July 1996