This entry is a pointer to a couple capacity planning documents. The first one I created was back in 1997, which I updated last in 1999. The 1999 Capacity Planning Document is embedded in the extended entry. (Format sucks) The updated version will be linked here.
|Standard Essbase Hardware Configurations||
The following system configurations are appropriate for small, medium and large Essbase installations.
Essbase will scale as large as needed. For more specific information about Essbase performance cases, read the audited benchmarks of the APB-1 Suite.
|Configuration||Application Examples||OS||HW Config.||Est. Ports / Cubes||Est. Price||Hardware Examples|
|The Junior System / Developer’s Workbench
This system is appropriate for working on small cubes which you don’t expect to share with more than one or two users. When production issues are not a concern and performance is not important, such as in development this configuration is appropriate.
||Wintel Junior||Single Processor Pentium >233MHz, 256MB RAM, 5GB Disk||5/ 3||$3,000||(anything)|
|UNIX Junior||Single Processor, 256MB Ram||5/3||RS/6000 F43P, Sun Ultra 2|
|The Bronze System
This is the system I think of as a departmental solution. It is the minimum configuration for a production roll-out in today’s corporation. It is the typical system most companies will use when they are just starting out with OLAP and only have one or two applications in mind.
||Wintel Bronze||Dual Processor Pentium II 233MHz+, 256MB Ram, 20GB SCSI Disk||20 / 5||$10,000||Compaq 3000, Dell PowerEdge 4200|
|UNIX Bronze||Dual Processor >200MHz, 256MB RAM, 20GB Disk||20 / 5||HP9000 K220, Sun Ultra 250,|
|The Silver System
Experienced OLAP users, most of those who have a D/W project in place or in process, and those who intend on ERP integration will be the most comfortable with a Silver configuration. Capital budget requirements are not too significant, and rapid deployment can be accomplished on such a system, with room for growth.
||Wintel Silver||Quad Pentium III 400+MHz, 2GB RAM, 100 GB Disk||50 / 10||$25,000||Compaq Prolinea 5500, Dell Poweredge 6100|
|UNIX Silver||Quad Processor, 2GB RAM, 150GB Disk||75 / 15||Sun Ultra 450, RS/6000 H50, HP9000 K570|
|The Gold System
The penultimate enterprise-wide delivery platform, the Gold standard is for implementers with top quality and 24/7 high performance in mind. More complex applications, worldwide rollouts, and large multi-cube single platform applications are appropriate for the Gold.
||Wintel Gold||Quad Pentium III @400MHz+, 4GB RAM, 200GB Disk||200 / 20||$40-50,000||Compaq Xeon 7000, Dell 6350|
|UNIX Gold||Six Processor, 4GB RAM, 300GB Disk||200+ / 25||Sun E4500, IBM RS/6000 S80, HP K580|
|The Platinum System
For multiple and special purpose very large single platform multi-cube databases in the 50GB+ range requiring maximum performance Essbase just screams on these platforms.
||UNIX Platinum||(Big)||300+ / 50+||SP/2, Sun E6000|
Server Performance - General Guidelines
Essbase wants to own the server and was designed to use as many resources on a physical machine as it can grab. The single most damaging thing for Essbase performance is co-location with a RDBMS or arbitrarily restrictive ulimits. With anything less than 128MB of RAM, Essbase performance is severly degraded. Essbase v5 is generally memory and processor bound. Single processor machines are not recommended for any but the most simple applications, demonstrations or sandbox development.
Calculation is the single most critical aspect of overall Essbase Server performance. As a conservative rule of thumb, expect Essbase to calculate 1GB/hour of data on an uncontested Quad Pentium II class machine with RAID5 SCSI. Consider your periodic processing window based on the number and size of databases to be calculated on your regular periodic basis. For example, looking strictly at calculation windows, a Wintel Silver machine can handle a single database which adds 12GB of calculated data per month.
Server Performance - SMP Guidelines
Each Essbase database or database partition will have it's own process. Within each of these processes, all Essbase operations will behave as follows:
|Calculation Script||Single Threaded||Multiple scripts can be executed from multiple clients. Different parts of a single cube can be calculated simultaneously. Application is available for query as calculations process. The application will not quiesce for other operations (load, build, shutdown) until all calculations are complete. Calculations can be aborted only by the initiating session.|
|Load||Single Threaded||Very rarely are there any significant performance issues related to data loading. There is but one optimization, sort input data according to sparse dimensions.|
|Build||Single Threaded||Application is unavailable during schema changes.|
|Query||Multi Threaded||One application can distribute queries across all processors on the server.|
Server Performance - Disk Guidelines (Essbase Version 5)
Essbase performs best with RAID 0+1. RAID5 will generally result in a 20% degradation in overall performance. Essbase data and index caches are maintained independent of the I/O subsystem. Essbase uses relative, not direct addressing to access blocks within its diskfiles. NFS mounted drives should not be used under any circumstance. Network Appliances can be used for database storage but Essbase should never be installed on such non-local drives.