Non-Functional Requirements

Normal activity is fairly modest. However, at peak times (such as when a new performance by a major star is listed), the site may experience sharp peaks of user activity. Such activity will often center on a single show, meaning that the performance requirements for the show page are almost the same as the welcome page. The following table shows the minimum performance requirements for the most performance-critical pages of the public Internet interface:

Page	Hits per second	Time (sees) to render page (discounting network transfer)	Average time (sees) to return page over 56k modem
Welcome	2	1	3
Display Show	2	2	5
Book Seats	2	3	5
Show Reservation	1	3	5
Payment Details	1	3	5
Process payment details (performance will partly depend on the speed of the external credit card processing system)	1	30	30

These are the minimum targets that will meet the immediate business requirements. The aim should be to far exceed them with a single Intel-based server running the app server, demonstrating the potential of the system for wider use within the Z Group (the database will be running on a separate machine). Special attention must be paid to performance characteristics under concurrent access, and especially to the following scenarios:

Heavy activity for one show or even one performance. This is a realistic possibility – for example, if a movie star makes a guest appearance on a single night during the run of a play.
Supporting concurrent requests for seats when a performance is almost full. This may result in multiple users trying to reserve the same small group of seats. It is vital that this does not seriously impair overall performance, and that the reservation database cannot be corrupted.
Effect on the box office interface of heavy load on the public Internet interface. It is vital that box office staff are able to do their job without being hampered by slow response times.

If necessary to achieve adequate performance, the following trade-offs are acceptable:

A new show or performance added by an Administrator may take up to 1 minute to show up on the web interface. However, the system must not require a restart.
The availability, or lack of availability, of seating for a particular class (as shown to public Internet users on the display show page) may be up to 1 minute out of date, although any time lag should be avoided if possible.

As cancellations are fairly rare, the remote possibility of a user failing to tutorial a seat because the desired class was marked as sold out, when in fact availability reappeared within 1 minute of the user requesting the display show page, is deemed to be acceptable in the interests of performance. The slightly greater possibility that the performance may have sold out after the data was cached is not considered a serious problem: after all, the user could have answered the telephone or discussed the performance dates with friends and family prior to following the link for a given performance date and seat type. Such delays will often be much longer than 1 minute.

Previous Next

Comments