Olio Application Specification

Goals

As we anticipate submission of multiple implementations of the same web application, we need to ensure that each implementation follows certain guidelines to make the implementations equivalent. This document is an attempt to lay out some of the feature requirements for the application. This is not a full-fledged document but rather is intended to be used along with the PHP application.

CSS Compatibility

All implementations of the Olio web application must use the same CSS, screen layout and images as the original implementations. Differing color schemes are encouraged as to segregate the looks of one implementation from the others. But beyond color, the images used as part of the web page decoration must all be the same.

Information shown on Web Pages

The web pages must exactly mimic the page for the current application. The list below only specifies the amount of data and the display/ordering semantics for the pages showing such data. It does not define the page layout which should be taken from the web application and style sheet directly.

1. Home Page

2. Event Page

3. User Page

Use of Ajax

Ajax is used in certain areas of these significant pages to communicate and fetch data for a page in the background without having to reload the page. Currently, the Ajax requests returns an XML that represents the DOM tree to replace in the current document. The followings list the places AJAX is used in the application:
1. Home page

2. Event page (logged on user)

3. User page (logged on user)

Data Loading

Sample data used for performance testing is loaded by a database loader. The database loader controls the number of entities loaded. Many software frameworks provide object-relational mappers (O-R mappers) that prescribe certain elements in the schema and how the schema is broken down (i.e. Rails demands a separate record id). In effect, the database schema may not be exactly the same for each platform/implementation. However, the number of entities loaded and their relationship must be the same no matter what implementation is used.

The tags - and any entity dependent on the number of tags - do not scale linearly with the number of concurrent users. They use a cumulative half-logistic curve to scale. Effectively, at low concurrent users, such entities will scale close to linear. As the scale gets higher, they will gradually top off and converge to a predefined cardinality.

The following table specifies the number of entities loaded with the loader.   Slight modifications to the data loader should be able to make it work with any platform-specific schema requirements.

Relationship

# of entities

# of entities
(n = 1,000)

Conc. users

n

n

1,000

Person

10 x n

10 x n

10,000

Friends

[2..28]/person

150 x n

150,000

Address

1/person

10 x n

10,000

Tags

1 - e^(-person/10000)
1 + e^(-person/10000)

1 - e^(n/1000)
1 + e^(n/1000)

2,311

Events

3 x tags

3 x (1 - e^(n/1000))
1 + e^(n/1000)

6,933

Event_Tag

[1..7]/event

12 x (1 - e^(n/1000))
1 + e^(n/1000)

27,732

Attendees

[10..100]/event

165 x (1 - e^(n/1000))
1 + e^(n/1000)

381,315

Comments

[0..20]/event

30 x (1 - e^(n/1000))
1 + e^(n/1000)

69,330


Note: Total number of records (avg) for 1,000 concurrent users is 657,621.

File Loading

Non-structured data (images, documents) used by the application are stored in an unstructured filestore. By default, we assume a normal filesytem – either a local filesystem for small single webserver deployments or a distributed file system like NFS. The PHP implementation does include code for MogileFS but this needs to be tested.

Geocoder Emulator

The web application implements a mashup using web services call to an external Geocoder. In the Olio environment, we emulate the geocoder using a very simple servlet running in Tomcat. This Geocoder Emulator is a required component. The emulator in the repository should be used as is by all implementations.