|
|
本章介绍确定内容传送系统的 Content Delivery Server 组件大小的常规指南。它包含以下主题：
用于确定内容传送系统 Content Deliver Server 组件性能和可缩放性的主要衡量标准是 Vending Manager 支持的每秒事务最大值 (tps)。事务是指对 Subscriber Portal（动态用户接口页面）或 Fulfillment Manager（内容下载、内容描述符和下载确认）的单个请求。
作为常规规则，Vending Manager 支持分配给 Vending Manager 的每 900MHz CPU 大约 30 tps，假设 Subscriber Portal 和 Fulfillment Manager 的每个部署最少 1 个 CPU 和 1GB 内存。假设数据库服务器资源足以负担此吞吐量。每分配给 Vending Manager 两个 CPU，数据库服务器就大致需要分配一个 CPU 和 1GB 内存。
如果在单独的部署中运行 Developer Portal 以及 Catalog Manager 和 Vending Manager 管理控制台，则应该每个部署至少附加分配一个 CPU 和 1GB 内存。最后，需要额外的内存以运行服务应用程序。按每个进程256K 计算。根据使用状况，可能还需要分配额外的 CPU 资源。
内容传送系统的实际吞吐量取决于很多因素，包括系统集成、部署大小和系统使用方式。上述指南是通过模拟 2,000,000 订户、168 类别（三级深层分层结构）中的 5376 内容项目和 48 种设备类型的内容传送系统来确定的。
尽管 tps 衡量标准取决于配置、大小和使用状况，但它是系统性能最客观的测量方法。可以通过很多方法将此衡量标准与内容传送系统支持的订户数相关。请注意，这些方法通常包含假设和不确定参数。您需要确定最适合于您的内容传送系统的方法。最好尝试各种不同的模型以查看是否能够获得类似的结果。以下示例可能适用于也可能不适用于您的状况。
铃声和图片体验表示每个订户每月只能下载一次。假设每次下载 100 个事务充分考虑到了内容浏览的量。这表示 1,000,000 个订户每月会产生 1 亿个事务。对应着大约平均 38 tps；假设在两小时中发生了一半的下载量，则高峰负载将达到 230 tps。根据此数据，可以估算出 Content Delivery Server 支持分配给 Vending Manager 的每个 CPU 大约 130,000 订户（130,000 这个值是用事务数 30 tps/CPU 除以 230 tps/1,000,000 订户的高峰负载，然后将商乘以 1,000,000 个订户而得到的）。
假设用户平均每 10 天连接一次且 30% 的请求在高峰时间抵达，则可以将订户连接频率设置为高峰期间每小时订户的 3%。如果进一步假设会话平均包含 30 个请求，则忙时负载估算值为每 1,000,000 订户大约 250 tps。通过这些假设，可以估算出 Content Delivery Server 支持每个 CPU 大约 120,000 订户。
根据这些示例和假设，可以粗略估算出 Content Delivery Server 支持分配给 Vending Managers 的每个 CPU 大约 125,000 订户。通过该假设，可以预计样例试用配置最多支持 125,000 订户（在试用条件下数量可能少于此数目）、小型到中型配置最多 2,000,000 订户、多销售配置示例最多 500,000 订户的四倍、大型配置示例 5,000,000 到 10,000,000 订户。
|
|
容量计划指南 Sun Java™ System Content Delivery Server，版本 2004Q1 |
版权所有 © 2004 Sun Microsystems, Inc. 保留所有权利。必须依据许可证条款使用。