Vignette Confidential: For internal use only.

Sizing Live CDS's for a Prospect

Contents

  1. Customer Parameters
  2. Definition of Terms
  3. Customer Scenarios
  4. Acknowledgements

Purpose

  • To help Vignette Sales work with prospects to quantify the hardware requirement for live Content Delivery Servers.

    • Audience

    Caveats

  • I've made simplifying assumptions so this doc is not meant to be authoritative regarding CDS sizing.
  • If you require more thorough technical discussion, please confer with Performance Engineering.

    • Revision History

    Customer Parameters

    We need to uncover these parameters (defined below) during customer interview:
    1. Peak Traffic
    2. Page Composition
    3. CDS Server Type
    4. CDS Overhead

    Definition of Terms

    Peak Traffic
    Definition: Estimated page views per hour to be handled by StoryServer-enabled web servers
    Page Composition
    Definition: An estimate of the ratio of static vs. dynamic components in an average StoryServer page
    Example: 40% dynamic, 60% static
    Reference Server
    Definition: One dual-CPU 200MHz running: No assumptions are made regarding differences between web servers, OS, tuning, etc.  (See Caveats)

    CDS Server Type

    Definition: The customer's preferred choice of quantity and clock speed for CPUs in their server(s)

    Analysis: The customer's servers can be more or less powerful than the Reference Server.  The scaling conversion is not quite linear but we assume here that it is.  (See Caveats)

    Example: A 4-CPU 400Mhz server will perform roughly 4x faster than the Reference Server.

    CDS Overhead
    Definition  The customer's preferred choice of CPU horsepower remaining unused during times of peak traffic.

    Analysis: Most customers (mainly their Systems Administrators!) prefer to avoid fully throttling their site, even during times of peak traffic.  This strategy enables a site to perform even during painful traffic spikes.

    Example: If a customer wants 50% overhead, then each server must only run up to 50% "hot" at peak.  The customer needs 2x the number of servers to handle peak traffic.  Calculated numbers should, of course, be rounded up to the nearest integer.

    Peak Traffic Conversion Factor

    CDS Performance

    (Reminder: The following is a rough estimate.  See Caveats)

    The Reference Server can serve:

    Customer Scenario: Motorola (Q1-1999)

    Customer Parameters (derived from customer interview)
    1. Peak Traffic: [500k page views per day]  =   [100k page views per hour]   (See Conversion Factor)
    2. Page Composition: 50% static (and 50% dynamic)
    3. CDS Server Type: 2-CPU 200MHz servers
    4. CDS Overhead: 50%
    We calculate the number of required CDSs as follows:

    We know the customer needs to handle:

    Now since the Reference Server can do: This customer will need: If their Systems Administrators want to run 50% hot then at peak they'll need twice that (0.8 x 2 = 2 CDSs).
    But if they prefer to use beefier boxes (e.g. 2-CPU 400Mhz) instead, they're back to a lower number accordingly.

    Customer Scenario: Launch.com (Q1-1999)

    Customer Parameters (derived from customer interview)
    1. Peak Traffic: [2M page views per day]  =  [400k page views per hour]   (See Conversion Factor)
    2. Page Composition: 25% static (and 75% dynamic)
    3. CDS Server Type: 4-CPU 200MHz servers
    4. CDS Overhead: 40%
    We know the customer needs to handle: Now since the Reference Server can do: Running 60% hot at peak requires an increase of 1.7x
    Running on twice as many CPUs per server decreases by (roughly) 2

    The calculations are:

    [(100k / 575k) + (300k / 72k)] times 1.7 divided by 2 = 4 live CDSs

    Acknowledgements

    Muchas gracias to these folks for helpful input during creation of this document:

    Vignette Confidential: For internal use only.
    Feedback to Matthew Reiser
    Hosted by www.Geocities.ws

    1