Papers in PDF format

3) Server Performance
The Web community is “performance elastic”. If users run into performance
problems and pages are not being served up quickly and consistently, they get
frustrated and leave the site or the web altogether. This was apparent at the
Internet Shopping Network in November 1995, when they experienced hardware
performance problems for a one week period and their order rates dropped by
50%. The activity recording, accessing and reporting software must be
configurable so as not to impact the primary web servers’ performance.
4) Scaleability
The system must be capable of scaling intelligently to accommodate peaks and
valleys in usage. This problem cannot be ideally solved by only adding hardware
to accommodate the peak usage period, as it leaves the system grossly underutilized
during light usage times.
5) Efficiently utilize all Hardware Resources
The software must respect the cost of hardware and must make the most efficient
use of all hardware components including CPU (including multiprocessing
systems), memory, disk storage, I/O and communication bandwidth.
6) Standard and Open
• API for legacy applications to write data to the information system:
There must be a standard mechanism for enabling third party applications
to write data into the database. There will be numerous third party
applications generating data that must be aggregated with data that the
activity accounting system captures directly from the web. The most
obvious example here is a third party demographic analysis application that
is compiling psychographic profiles for users off-line. This data will need
to be matched against the user profile when the system detects the user is
on a website.
• API for reading from the information system:
This is the primary API required by most third party applications, whether
they are performing reporting and analysis functions or dynamic
advertisement rotation. They will all need access to the information
collected by the activity recording, accessing and reporting system. This
access must be clean and structured in a way that supports the data model
of the application. One API for all classes of applications will not work.
Each “class” of applications will have a different set of requirements for
viewing and accessing this information. This API must be extensible
without forcing change in the existing API interface.
______________________________________________________________________________
The Aria Architecture Page 10 Andromedia, Inc.
White Paper July 1996