The Building Blocks Of An Architecture - IBM BS029ML - WebSphere Portal Server Self Help Manual

X, the actual anticipated estimated rises to 7,500 concurrent clients after two years time,
which then increases the percentage to 18.75%.
Normally, it is common for business requirements to state that a Portal should be able to
handle X number of clients concurrently.
It is important to distinguish between concurrent clients and concurrent active clients; as
such, terminology is often misinterpreted between different parties. Concurrent active clients
have both an active connection to the HTTP server as well as at least one thread of execution
running in the application server. At any point in time, many of the clients connected to the
Portal are not active; they may be thinking, reading, or even drinking coffee. These are
considered as inactive concurrent clients, or more generically as concurrent clients. Based on
our experience, a good starting point is to assume that for every single concurrent active
client there are approximately 10 concurrent inactive clients (1:10). Theoretically, therefore,
an application server capable of supporting 100 active clients will support approximately 1000
concurrent clients (active + inactive).
This assumption breaks down somewhat when the characteristics of WebSphere Portal
Server shift away from that of being a traditional Web-based solution. For example, a Portal
performing more back-end work will effectively shift the assumed work pattern from that of
being a traditional Web-based solution to that of an On-Line Transaction Processing (OLTP)
solution. Such an OLTP solution will place greater demands on system resources, with a
reduced supporting ratio of approximately 1:5 or less.
A further point of debate between different parties is the understanding of Peak Load or
Arrival Rate. It is important to recognize that it may be necessary to plan for such situations
when many users simultaneously access the Portal solution at the same time. This generally
breaks any rule of thumb for concurrency and is indicative of such situations as logins, each
morning between 8am and 9am, or campaign launches. Under such circumstances, is it only
possible to honor each request by
Attention: A sizing estimate should only ever be used as an approximation of the
hardware resources required to support the proposed implementation. Actual experiences
may vary from the sizing estimate for many reasons. The degree of variability can range
from small to very significant. As such, there is no substitute for not undertaking a full
capacity planning and performance tuning exercise. Failing to implement this critical part of
any project plan is planning to fail.

2.2 The building blocks of an architecture

When faced with the challenge of architecting a WebSphere Portal Server implementation, it
is often useful to take a high-level approach to first define the logical components that
comprise the very architecture that is about to be designed.
For the experienced IT Architect and Portal Practitioner, this commonly embraces two
aspects of design; the component model and the operational model. Component models are
typically focused on identifying the components, their responsibilities, and characteristics
required to deliver the solution requirements. At a conceptual level, the component model
documents the technical architecture at a very high level and does so in a technology
agnostic manner. At a specification level, the component model documents the required
specifications and corresponding realization of all components, which ultimately will be
placed on the operational model, together with a description of their interfaces, dependencies
and collaborations. In common terminology, the component model addresses the logical
16
IBM WebSphere Portal V6 Self Help Guide
Planning for the Peak
.