| Sun Java System Content Delivery Server Capacity Planning Guide |    
|
| C H A P T E R 3 |
|
Deployment Sizing |
This chapter provides general guidelines for sizing Content Delivery Server component of you content delivery system. It covers the following topics:
Performance and scalability of Content Delivery Server is measured by the maximum number of transactions per second (tps) supported by a Vending Manager. A transaction is a single request made to a Subscriber Portal (dynamic user interface pages) or a Fulfillment Manager (content download, content descriptors, and download confirmations).
As a general rule, the Vending Manager supports approximately 30 tps per
1280 MHz CPU allocated to the Vending Manager, assuming a minimum of 1 CPU and 1 GByte of RAM per deployment of the Subscriber Portal and Fulfillment Manager. This throughput assumes sufficient database server resources. The database requires approximately one CPU and 1 GByte RAM for every two CPUs allocated to the Vending Manager.
If you are running the Developer Portal and the Catalog Manager and Vending Manager administration consoles in separate deployments, you should allocate at least one additional CPU and 1 GByte RAM per deployment. Finally, you need additional memory to run the service applications. Count about 256K per process. Depending on usage, you might also need to allocate extra CPU resource.
The actual throughput of a content delivery system depends on several factors, including system integration, deployment size, and system usage patterns. These guidelines were determined experimentally through simulation of a content delivery system with 2,000,000 subscribers, 6192 content items in 216 categories (in a three-level hierarchy) and 96 device types.
Although dependent on configuration, size, and usage, the tps metric is the most objective measure for system performance. There are several ways to relate this metric to the number of subscribers your content delivery system supports. Note that these methods usually contain assumptions and uncertain parameters. You need to determine what method is most appropriate for your content delivery system. It is a good idea to try a couple of different models to see if you obtain similar results.
The estimates on subscriber usage based on downloads given here are based on the execution of performance tests using different load types. These results are highly dependent on the hardware configuration and the network environment. The hardware used for these tests is given Hardware and Software Guidelines for a Basic Configuration. The network environment such as WAP gateway, security services, firewall, external LDAP and such were not considered in the test execution.
TABLE 3-1 shows the download per second per CPU and the database to application CPU ratio for the given download types:
Downloads done from the Device Portal Interface (DPI) involve a number of browse operations (approximately 96) before the download takes place in the device. Only 30% of the sessions result in download operations.
Downloads done from the Web Portal Interface (PWI) involve a number of browse operations (approximately 70) before the download takes place in the device. Only 30% of the sessions result into download operation.
Download only involves just the purchase and download operations and no browse operations. 100% of the sessions result into download operation.
Combination downloads involve a mix of operations with 50% of the operations done in the DPI scenario, 25% of the operations done in the WPI scenario, and 25% of the operations done in Download Only scenario. 30% of the total sessions result in download operations.
The data set used for these tests are as follows:
This section provides some examples that makes use of the data provided in TABLE 3-1. The calculations for each example are based on the assumptions for that example. Depending on the number of subscribers, the peak download time, number of contents, machine capacity, and the network environment, you need to determine what the hardware requirements are for a live deployment.
Example 1 uses the following assumptions:
1,000,000 subscribers perform 1,000,000 downloads per month using the device. This is equivalent to 0.38 downloads/sec in a one month period. Based on these assumptions, 0.49 downloads/sec are expected to be supported by the CPU, dependent on the hardware and the network environment used. In this example, approximately 1,289,000 subscribers can be supported per CPU (the value 1,289,000 was derived by dividing 0.49 by 0.38 and multiplying the quotient by 1,000,000).
Example 2 uses the following assumptions:
Based on the download rate assumption, 2.3 downloads/sec are expected to occur at peak time. Given the CPU capacity of 0.49 downloads/sec, approximately 200,000 subscribers can be supported by the CPU, Conversely, 4 app server CPUs and 1.30 (approximately 2) database CPUs are required to support this kind of download rate.
Example 3 uses the following assumptions:
1,000,000 subscribers perform 1,000,000 downloads per month using the device. This is equivalent to 0.38 downloads/sec in a one month period. Based on these assumptions, 0.16 downloads/sec are expected to be supported by the CPU, dependent on the hardware and the network environment used. In this example, approximately 421,000 subscribers can be supported per CPU (the value 421,000 is derived by dividing 0.16 by 0.38 and multiplying the quotient by 1,000,000).
Example 4 uses the following assumptions:
1,000,000 subscribers perform 1,000,000 downloads per month using the device. This is equivalent to 0.38 downloads/sec in a one month period. In a typical combination of operations mentioned in the TABLE 3-1, 0.38 downloads/sec are expected to be supported by the CPU, dependent on the hardware used and the network environment used. In this example, approximately 1,000,000 subscribers can be supported per CPU. Conversely, approximately 1 app server CPU and 2 database servers are required for this type of download rate.
Assume that the average user connects once every ten days and that 30% of a day’s request arrives within a peak hour, you can then set the subscriber connection frequency to 3% of the subscribers per hour during periods of peak load. If you further assume that the average session consists of 30 requests, you arrive at a busy-load estimate of about 250 tps per 1,000,000 subscribers. With these assumptions, you can estimate that Content Delivery Server would support about 120,000 subscribers per CPU.
Based on these examples and assuming the actual facts are somewhere in between, you can estimate that Content Delivery Server supports roughly 125,000 subscribers per CPU allocated to the Vending Managers. With that assumption, you can expect the sample trial configuration to support a maximum of 125,000 subscribers (probably less under test conditions), the small to medium configuration up to 2,000,000 subscribers, the multivending configuration example up to four times 500,000 subscribers, and finally, the large configuration example between 5,000,000 and 10,000,000 subscribers.
| Sun Java System Content Delivery Server Capacity Planning Guide | 820-1939-10 |
|
Copyright © 2008 Sun Microsystems, Inc. All Rights Reserved.