Can
WASD Handle The Load?
Universidad de Málaga (University of Malaga, UMA) is a center
for higher education covering 4 campuses, 19 faculties, 65 undergraduate
courses and postgraduate programs, with 3760 staff and 40,000 students,
located on the Costa del Sol in southern Spain. Many thanks to UMA
Administration for permission to publish this data.
UMA is a
significant user of VMS and the largest WASD site, both in terms of
deployment and throughput, that the author is aware of.
The UMA front-end
system is an ES40 with four EV68A, 833MHz CPUs, 4GB memory, running
OpenVMS 7.3-2 and TCP/IP Services 5.4.
At the
commencement of the 2006-2007 academic year student registration and
associated staff activities were performed using on-line applications
and other resources. The Web server for this suite was WASD
v9.1.4, PHP Version 4.3.10 (via the CSWS PHP v1.3 engine) along with a
number of in-house front- and back-end applications distributed across
multiple VMS and Linux-based systems. Although a user of WASD
since 2003 (and other Web technologies on VMS previously) this was the
first time a student registration event had been so heavily dependent
on Web availability.
The following
three images show the WASD Server Activity report at various times over
the two week registration period. The activity report is
generated in real-time from server statistics stored in a global
common. The data are accumulated with a per-minute granularity
and include total and peak for network connections (includes persistent
connections ("keep-alive") and those in-progress), requests processed,
and network bytes transfered. Total per-minute requests are
the dark-blue bars; total bytes the light-blue. A red line shows
the accumulated average requests for the displayed period; the magenta
line average bytes transfered. In the lower portion of the graph
are two other lines; one dark blue indicating the network connection
peak during each minute and the white for peak requests being
processed. The green vertical lines indicate a server
restart. These are major changes to server configuration, most
changes are handled dynamically through configuration reload. UMA
operates with two WASD "instances" and so server
restarts do not interrupt site availability in the least.
Registration: Day One
The above graph
shows 24 hours from 6AM on the first day of registration. During
that period 2.7 million requests have been processed and 24 GB
transfered. Network connections peaked at 837.
Requests-in-progress peaked at 553 which is a very large number.
An obvious couple of maxima in the peak connection and request data
(lower lines) indicates some slow and/or anomalous back-end processing
causing occasional delays and request congestion at the front-end. These
persisted during the registration period but were gradually identified
and resolved over the two weeks. WASD handled this front-end
congestion without significant issue using it's internal queuing
facility ("throttle") which had been applied to potentially high-impact
scripting resources during registration planning and testing (and was
also dynamically adjusted to better address observed behaviours during
live processing).
Registration: Week One
This second
graph shows Monday to Friday of the first registration week.
Over those five days nearly 12 million requests have been handled and
104 GB transfered. It must be remembered a lot of this was
dynamic content from PHP or other script generation. The total
number of requests processed in any one minute was 5934, or a sustained
mean of almost 100 per second. A few more of those anomalous
peaks in network connection and request processing can be seen, with
requests again an astronomical number, 842. WASD counts
"throttled" (queued) requests as in-progress (as they have been
accepted and the response initiated before further processing becomes
queued). The five day average (over the full 24 hour day) was
approximately 2500 requests/minute. Average response time (not
shown in these images) was approximately 700mS. Increased load
and the processing anomalies contributed to this extended
duration. Normally UMA averages less than 400mS for a response.
30 Million Requests and a Quarter Terabyte Later ...
This final graph
shows the full two weeks from the Saturday morning preceding the first Monday
of registration.
During this period the site has handled nearly 30 million
requests and over a quarter terabyte in traffic! The weekends are obvious
with noticably less traffic than business days. It should be noted
that UMA is never a particularly quiet site. Weekend traffic typically
drops to only 30-50% of weekday traffic. UMA very much provides 24x7 on-line
services.
Conclusion
Can WASD handle
your load? Almost certainly!
Mark
Daniel
24-OCT-2006