Monday, June 27
Scalibility - Distribution of Software and Hardware Components and Sizing
This post will discuss aspects related to scalability. How to implement
scalibility by adopting techniques such as distribution of software and hardware components and sizing etc.
What Is Scalability?
What if the user population increases suddenly, the geographical distance of the users from the portal increases, number of portal functionality increases, the number of objects in the portal content directory increase or the size of data used in the KM application increase. The portal’s performance should not be affected by all these factors. The measure of its strength to withstand all these adversities is called scalability.
Scalability is important because by conducting appropriate load tests, you can determine aspects such as how many incoming HTTP requests can be processed in an hour, how many concurrent users can use the portal without significant performance degradation, and how many transactions can be executed in SAP R/3 from the portal.
How can scalability be implemented ?
This can be done by adding new hardware, such as servers, RAM, and hard disks, to maintain the portal’s performance at satisfactory levels with increasing loads. Also you can distribute portal components to different physical machines so that enough resources are available.
Sizing for Performance and Scalability
Sizing the various components is very important part of portal infrastructure design so that performance and scalability are good under heavy load conditions. Sizing determines the hard disk, memory, CPU, I/O, and network load requirements so that the response time is satisfactory.
Portal can be implemented in phases ranging over say 2 to 5 years. Is sizing is ok, performance will not suffer when system load increases due to increased users, increased workload activity, and other factors.
Sizing determines the success or failure of the project so it must be done ahead of the project start. But the factors which affect scalability and sizing are very dynamic in nature. They can increase of decrease during the implementation cycle also or after the portal has gone live, so sizing has to be kept in process. It is an ongoing activity and it part of portal maintenance.
Important - Proper sizing ensures that the portal performance does not suffer due to increased load.
The factors that influence sizing are database versions, portal software versions, customer-related factors and operating system versions.
customer-related factors can be the workload on the system, the nature of users in terms of the intensity of use of applications, number of users, geographical distribution of users,the amount of customizing involved.
Factors that can affect sizing are :
• Number of top-level menus in top-level navigation (TLN)
• Number of nodes in the detailed navigation iView
• Layout of the portal desktop and the portal framework page
• Number of iViews in the content area of the portal desktop
• Number of Java iViews that use Java Connector Remote Function Call (JCO RFC)
• Number of iViews that fetch data from SAP and non-SAP backend systems
• Custom navigation iViews and the programming model used to create those iViews
• Number of roles and groups created in the UME database
• Number of concurrent users using the portal
• Think time between two successive clicks
Etc…
It is very important that data about the above stated factors is gathered during the requirement gathering phase and thought is given to it well ahead. This will result in smooth operations after go live.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
You are welcome to express your views here...