Professional Java Development with the Spring Framework
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 (secs) to Render Page (Discounting Network Transfer) | Average Time (secs) to Retune Page over 56K Modem |
|---|---|---|---|
| Welcome | 2 | 1 | 3 |
| Display Show | 2 | 2 | 5 |
| Book Seats | 2 | 3 | 5 |
| Show Reservations | 1 | 3 | 5 |
| Payment Details | 1 | 3 | 5 |
| Process payment details[a] | 1 | 30 | 30 |
|
[a]Performance will partly depend on the speed of the external credit card processing system. | |||
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 application 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 groups 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 tradeoffs 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 book 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.