Database Reference
In-Depth Information
reporting applications usually have more concurrent retrieve/query operations that
cause higher I/o and to a lesser extent CPu usage.
Planning applications have more concurrent calculation operations driving high
CPu and I/o; one of the oracle tuning guides states they have benchmarked a plan-
ning system with 2000 users to work with 8 cores (this had to be a very simple planning
system), in reality, planning systems tend to be driven by the finance or operations orga-
nizations and tend toward being more complex.
The following sections show general sizing rules. In specific instances, these will not
meet either performance goals or scaling goals; generally the more resources you throw
at the hardware the better performance you can expect. That being said, hardware is not
a replacement for proper design and application tuning. once the hardware is up and
going, you then need to count on the functional team to tune the specific application
settings to fit the server size. As an example, if you have limited server memory, you
may decide to make the caches smaller than would be optimal. overly large caches also
will not provide any additional benefit and can stress the system resources as well. For
instance, consider a small server having 2 gb of free memory where a developer added
an additional 2 gb of data cache to a block storage option (BSo) cube. This type of
action could tip the server over the edge and begin constantly using the disk for virtual
memory, which is a very bad situation.
1.4.3 Essbase and CPU Cores
Intel is constantly increasing the core count of its processors. When I started out with
servers in the 1990s, a server meant one CPu and the server's main jobs were to pro-
vide shared file storage and print services, such as netWare and early Windows Server
platforms. Application tasks were relegated to the desktops, minicomputers, and main-
frames. As commodity servers became more and more complex, they began being used
for tasks more complex than file and print services.
Essbase calculations are bound by processor speed, number of cores, or maximum
disk throughput. When money is not an object, you want the fastest clock-speed CPu
with the most number of cores to provide the highest performance. When using Intel-
compatible CPus, I recommend at least a 3-ghz clock-speed.
The rule of thumb for number of physical cores for Essbase is 1 core per every 30
users; start out with 4 cores. try to limit maximum licensed users to 1000 per server and
maximum concurrent users to 250.
1.4.4 Web/Java Server CPUs
When focusing only on Essbase, the Java application servers are mainly used for Provider
Services, Financial reporting, and Web Analysis. A routine configuration step is tun-
ing the maximum heap size for the Java virtual machine (Jvm). Allocate at least one
four core server per every 250 users. For very large-scale configurations, double the core
count and memory rather than doubling server count.
1.4.5 Memory
memory is cheaper than ever before; in 1995, I had a machine using FreeBSD unix
on the Internet as a shared server and “invested” nearly $900 in 24 mb of rAm. In
2011, I purchased 24 gb of ram for $1000. over 15 years later, I purchased 1000 times
the rAm for less money when accounting for inflation. Skimping on memory can
and will affect your application's performance. When a server runs out of memory,
