Hardware Requirements

In general, Connect Daily is a very efficient program that puts minimal requirements on hardware. A single Pentium 4 computer is sufficient to run around 300 copies of Connect Daily. That is 300 churches, schools, businesses, or government agencies can all have their Connect Daily calendar installed on the same machine and receive good performance. An older machine, a P3 600 w/ 1GB of RAM hosted around 60 copies of Connect Daily with CPU utilization between 3-10% during the day.

To determine how well Connect Daily would scale, we created a scalability test plan. The results of this testing and the configuration of the system are shown below.

Narrative Test Results

During testing, we achieved a peak throughput of 1,404 requests per minute or approximately 23.4 requests per second. This represented 747,177 bytes per second throughput or approximately 6Mb/s. The table below shows the throughput rates for different periods:

This level of throughput would require a server connection speed approximately equal to four (4) T1 circuits.

Aggregate Test Report Screen

The Average, Min, and Max fields refer to the request times in milli-seconds.

During testing it was noticed that the Week View servlet was taking about twice as long as the other servlets to generate output. Investigation revealed that Week View was getting the data set and invoking OutputCurrent Week which was also getting the data set. OutputCurrent Week was modified to use a data set stored by WeekView. This brought performance into line with the other servlets. This would indicate that database access may be a significant issue.

It is interesting to note that the Year View servlet was a full 5 times faster than the Month View servlet. This servlet generates output without any database interaction. This supports the theory that the database is the bottleneck in the application.

Scaling Suggestions

If you are finding that Connect Daily isn't meeting your performance requirements, here are some suggestions to achieve higher results.

1. Multiple CPUs/Higher Grade CPUs. The testing was done with a single consumer grade 32 bit P4 CPU. A CPU with larger cache or multiple CPUs would probably scale linearly.
2. Separate the database from the application server. Get a second dedicated machine to act as the database server for the application server and link the two using a dedicated high-speed interconnect. Along with separating the database, you may want to experiment with commercial databases to see if better results can be obtained.
3. Configure multiple application servers. There are two ways of doing this:
   1. If you are fronting the application server with a standard web server, then the re-director can be configured to load balance servlet requests across multiple application servers.
   2. If you are using the application server in stand-alone mode, we recommend you use a hardware load balancing device to map requests to multiple back-end units.

Server Configuration

Hardware

Supermicro 5014C-MT 1U Rackmount
3.0GHz Pentium 4 CPU w/ 1MB Cache
2GB RAM
2 200GB Seagate SATA Drives configured for RAID 1 using Linux Kernel RAID

This server was configured for hosting up to 200 copies of Connect Daily at the same time. It was not designed or optimized for raw throughput.

Software

SUSE Linux 9.3 w/ Patches (Kernel 2.6.11.4)
Apache Tomcat 5.5.9
Sun JDK 1.5.0 step 04 (Server VM w/ 512MB specified for mx and ms).
PostgreSQL 8.0.3
Connect Daily version 3.2.2

Dataset

Connect Daily demo calendar set w/ 20 or so calendars containing around 300 events. The month tested contained 89 events.

Client Configuration

Hardware

Intel Pentium 4 2.8GHz
1MB CPU Cache
1GB RAM
200GB IDE HD

Software

Windows XP SP2 w/ patches
Jakarta JMeter 2.0.3
Sun JDK 1.5.0 Step 02

JMeter Test Plan Description

A test plan was created using Jakarta JMeter 2.0.3. It had the following elements:

• Thread Group configured w/ 15 Threads
• Graph Results Listener
• Aggregate Report Listener
• Random Order controller to randomize order of requests.
• Constant Timer w/ 300 ms Delay between Each Request
• Month View Calendar HTTP request
• Week View Calendar HTTP request
• Day View Calendar HTTP request
• Year View Calendar HTTP request
• Output Current Week Servlet HTTP request

Using this test plan, JMeter started 15 threads. Each thread would make a request and then sleep 300 milliseconds (0.3 seconds) before issuing its next request. Each of the 5 HTTP requests was sent once, in random order, and then the thread would start the whole request sequence again.

This test plan is available in the cdaily-3.4.16/WEB-INF/misc/JMeterPlan directory.