Enterprise Knowledge Platform. Capacity Planning Guidelines. Prepared: Version 1.4

Transcription

1 Enterprise Knowledge Platform Capacity Planning Guidelines Prepared: Version 1.4

2 Enterprise Knowledge Platform Capacity Planning Guidelines Document Information Document ID: EN148 Document title: EKP Capacity Planning Guide Version: 1.4 Document date: 18 January 2009 This document may be revised from time to time. Please check NetDimensions Support site at for updates to this and other documents or send an to to request the most recent version. Please report any errors or feedback with this document by sending an to Copyright Information Copyright by NetDimensions Ltd. All Rights Reserved. Information in this document is subject to change without notice. The software described herein is furnished under a license agreement, and it may be copied only in accordance with the terms of that agreement. No part of this publication may be reproduced, transmitted, or translated in any form or by any means without the prior written permission of NetDimensions Ltd. All company and product names used herein may be trademarks or registered trademarks of their respective companies unless stated otherwise. How to Contact NetDimensions Support US toll-free number support@netdimensions.com General Enquiries info@netdimensions.com

3 Table of Contents Overview...1 Purpose...1 Related Documentation...1 Understanding LMS Production Site Usage Patterns...2 Concurrent User Activity...2 CPU Usage...3 Database Size and Disk Storage...4 Network Activity...5 Memory Usage...7 Getting Statistics From Live Systems...10 Rule-of-Thumb Base Guidelines...12 Typical Client Configurations...16 Internal Benchmark System Example...18 Overview...18 Interpreting Benchmark Data...18 Testbed...19 Performance Measurements...21 Disk Size Planning...28

4 Enterprise Knowledge Platform Capacity Planning Guidelines Page 1 Overview Purpose This document is intended to illustrate typical measurements of the performance of EKP under load and to provide sufficient technical data to enable capacity planning for new systems. Three categories of information are generally included herein: Rule-of-thumb capacity planning guidelines; Representative real-world configurations; Measurements from an internal benchmarking exercise; If you should have any sizing or capacity planning questions, please feel free to contact us at support@netdimensions.com. Related Documentation This document does not cover details of configuring and tuning a specific environment or setting up a load-balanced architecture, and the reader is referred to the following documents for this level of detail: EKP 5.x Installation Guide EKP 5.x Configuration Guide EKP Content Server Setup Guide EKP Multiple Instance Configuration and Load Balancing.

5 Enterprise Knowledge Platform Capacity Planning Guidelines Page 2 Understanding LMS Production Site Usage Patterns Based on measurements from production sites that range from a total of 500 users to those with over 500,000 users, the following observations and measurements regarding usage patterns for an LMS environment have been obtained with the purpose of presenting some real-world configuration experiences. It is important that you understand the nature of such an environment in order to apply the capacity planning guidelines discussed later in this document, as an on-line learning environment is unlike most other application environments, and has its own workload profile that is particularly demanding of corporate networks. The following subsections discuss the essential behaviors of an LMS environment along the following key dimensions: Concurrent User Activity CPU Usage Database Size and Disk Storage Network Activity Memory Usage These guidelines are derived from measurements and practical experience gathered from hundreds of EKP production sites, and so provide a realworld estimate of what you can expect when configuring a system of your own. These guidelines are up-to-date for EKP 5.5, although individual versions of EKP do not necessarily exhibit any significant resource requirement differences, especially when compared to the impact that organization specific workload profiles have on a system sizing. Concurrent User Activity Most sites concurrent user usage levels tend to vary from 0.5% to 5% of the total user population, with the average being about 1.5%. These figures can be deceptive, however, for sites that are global and operate 24x7 may have an uneven distribution of users, so the actual populations as distributed across different time zones will exhibit different usage patterns throughout the day. Therefore, basing sizing estimates purely on the total population can be overkill. For example:

6 Enterprise Knowledge Platform Capacity Planning Guidelines Page 3 One production global site with 68,000 users typically has an average of 300 users during some parts of the day, and 1000 concurrent users during nighttime (relative to the server location) as the user communities in other regions come on-line, with an infrequent peak experience of over 2000 users. The larger the site (e.g. > 30,000 users), the more predictable and consistent the above figures tend to be a small site is somewhat more variable in terms of the relative % of users online at any given time. The 1.5% average on-line figure seems to be pretty consistent across different sites, although any give site can vary because of demographics and company workload requirements. As with any application system, the hardware should be configured for the expected PEAK workload, not the AVERAGE workload. Peaks very often occur when the training organization launches a new program, as this results in a surge of new users on the system. This is not a problem, but is to be expected and should be incorporated into sizing plans. CPU Usage Most sites are not CPU bound as the majority of the users (often 80% of the on-line user base) are running courses and are not navigating through EKP, and the course tracking data (e.g. AICC/SCORM) recorded from this course activity is very low impact. Thus, the CPU workload and the database activity for EKP installations tends to be very manageable. Direct use of the LMS by the user (e.g. examining their transcript, enrolling in a courses etc.) is much more resource intensive than using the courseware itself (which is mostly a matter of downloading web pages and its elements), and so EKP has numerous optimizations to minimize the database and CPU intensive tasks, thus resulting is quite a high ceiling for the overall concurrent user limit. This ceiling assumes that some fair number of the on-line users are performing courseware work, and a smaller number are performing EKP functions. Generally speaking, you should consider 2000 (although we have one production site with 3000 on a single instance) concurrent users to be a practical limit on a single instance of EKP unless it is pure on-line course delivery workloads larger than this should be configured using loadbalancing and multiple EKP instances. This is not due to any limit of EKP

7 Enterprise Knowledge Platform Capacity Planning Guidelines Page 4 since it is multi-threaded, but measurements done during benchmarks of high-end configurations indicate that responsiveness of SMP processors and the JVM threading can be improved when using multiple instances, and this reduces other internal OS and hardware bottlenecks that occur under high loads between the web server, Java servlet container environment, and disks. This is not a surprise, as most very high-end applications benefit from redistribution of the overall workload to multiple processes/machines. One area to highlight regarding intensive CPU use is reporting, as any report that is running against tables containing millions of rows will consume significant system resources. EKP has some options to control management of reports to minimize impact to on-line users. Most small sites rarely have tracking data table sizes that exceed a few hundred thousand rows, which does not appear to have a significant impact on overall responsiveness, but any site with multiple years worth of data and millions of rows in the AICC, transcript, and test related tables should also consider using a load-balanced configuration to ensure smooth on-line operations. One final observation: Multi-core CPU systems tend to be more responsive that a faster single CPU system in a server environment. For example, a 2.4Ghz two core CPU system server is preferred over a single core 3.2Ghz CPU system. Because a site is typically running a cooperating Web Server, a Database Server, an Application Server (with EKP), plus OS services as independent processes, the SMP approach evens out the work activity among these different processes better than the typical task switching on a single CPU. Database Size and Disk Storage The size for most databases is relatively small when compared to the space required for the courseware. A production site running for 3 years with 15,000 users typically has a database disk-space requirement of around 5GB, whereas the disk storage for the courseware would likely be 50 to 100 GB for the same system. The average course from 3 rd party suppliers is about 10-30MB, depending upon the supplier. Internally developed courseware often tends to be larger as tools that generate flash, plus audio and video components, are often used. So, using 20MB per course is a reasonable estimate when calculating overall disk requirements, but your courseware may need more. Given that disk space is relatively inexpensive and 50GB is easy to configure, this tends to not be a problem on most production sites.

8 Enterprise Knowledge Platform Capacity Planning Guidelines Page 5 The database itself mostly has a relatively fixed amount of user records and course catalog data that varies by only minor amounts over the years. The training history, course tracking data, and test results are where the highly variable amounts of data come into play, as entries are made for each user enrollment, and each user test attempt. Thus, these tables can grow quite large. There are EKP sites in production that have 5 million entries in the AICC and transcript tables, plus 5 million in the test question table(s), but these are very high end environments (e.g. 200,000 users) and are not representative of normal sites. EKP also does extensive auditing, but this information is automatically cleaned up by EKP (e.g. it routinely keeps only the last 6 months of data in the database), so it does not present a significant management issue. The user related data mentioned above is considered key corporate operational information and is often kept on-line for at least 5 years (depending upon company policy) and so must be catered for in the overall database sizing calculations. Do remember to leave an adequate amount of server free storage (50% is the industry norm) to cater for workspaces, backup activity, unanticipated growth, etc.). Network Activity Network bandwidth is the key, key, key issue in an on-line learning environment. Unfortunately, this is also the part that is the most variable across different sites since it is determined by the courseware, not by anything EKP specifically does. Once launched, courseware is delivered to the user browser by the web server (e.g. Apache or IIS) or the application server (e.g. WebSphere, BEA Tuxedo) and so is no longer directly managed by EKP until tracking data is returned. How efficiently the web server manages static file delivery is a factor in speed and responsiveness of course content. The key factors in determining the network bandwidth impact of the courseware include: Size of the courseware and its components; Media types used (video, audio, flash, Java applets, ); # of concurrent users of the course(s); Frequency of user activity;

9 Enterprise Knowledge Platform Capacity Planning Guidelines Page 6 Proxy usage; Link segment bandwidth limits within individual offices; The EKP bandwidth requirements are insignificant when compared to the courseware requirements. The typical EKP page is approximately 4KB, so its impact on network usage pales in comparison to the courseware activity. The unfortunate message for this topic is that it is very inaccurate to quote general network usage and response time figures without knowing more about the usage parameters as mentioned above, which means individual sites almost always need a custom network usage review, rather than relying on rule-of-thumb guidelines. As an example calculation, the following two sections give some background into the two key elements of a session: EKP page traffic; Courseware page traffic Some sites have assumed a general usage level of 20kbits per sec per user, but as stated above, this figure is dependent upon many variable factors much more so than HW sizing issues as described in the previous sections. EKP Bandwidth Usage Each EKP screen typically is about 4KB for the average user. This usage is optimized by splitting the screen into 3 frames as follows: 1. The top Frame is typically loaded once and is used to hold the logoff/help buttons. It is usually < 4KB with background graphics; 2. The Left Frame contains the menu and it is also loaded just once. It is also around 8KB; 3. The main frame is loaded many times with the individual user requested screens (training history, notepad, etc.) 4. Course tracking data, which must be returned to the central system, is typically about 1KB per user session (max). A typical user session (based on production site statistics) averages about 12 EKP screens over 30 minutes (as most user online time is spent in a course, not on EKP screens. Thus, the EKP bandwidth load for a typical user is: Login page 8KB; 4KB + 8KB for top/left frames; 12 * 4KB for user screens 1KB tracking data;

10 Enterprise Knowledge Platform Capacity Planning Guidelines Page 7 This comes to 69KB per user session (averaged over 30 minutes elapsed time ) for EKP screens. So, 1000 concurrent users over a 30 minute period would consume an average of 0.64KBytes/sec on the network for pure EKP traffic. This is trivial. Course Bandwidth Usage As mentioned above, modules are typically 20Mb in size and roughly take 4 hours (this is typical of Skillsoft type courses recently, modules have begun to be structured into smaller chunks, e.g. 20 minutes) to complete. Therefore at a very general level, as a student pages through one title he/she would consume (20,000Kbytes / 14,400sec) or 1.38Kbytes/sec of bandwidth per active student. Your Network Numbers Obviously, your calculations would take into account the courseware and usage patterns for your user community (e.g. maybe larger courses because of video, plus shorter usage times). In addition, remember that network bandwidth is not 100% available at all times, as average network efficiency typically borders on the 65% level of the rated value, plus various congestion points (firewalls, gateways, etc.) may limit that figure even further. Memory Usage An EKP environment is very tolerant of memory configurations up to a point, and it is possible to set memory use guidelines so that it can naturally grow to its optimal working set size (rather than pre-allocating fixed memory). Because EKP is a J2EE based application, you need to be very careful to not undersize the memory configuration, as the JVM can suffer severe performance penalties if it has been allocated insufficient memory. General guidelines are: The minimum JVM memory used by EKP is typically 128 MB. This is often suitable for demo sites and just represents the base memory usage for the application. Production servers can expect to use about 512MB, with peak growth to 1GB being normal. Note that on a 32- bit OS (e.g. Windows Server 2003) you are limited to approximately

11 Enterprise Knowledge Platform Capacity Planning Guidelines Page 8 1.5GB for the Java Virtual Machine EKP memory use is not very sensitive to the number of concurrent users, as the typical user session only requires about 5KB to 10KB overhead. Thus, a modest memory configuration can support quite a lot of concurrent users. However, reporting is a different story altogether, and while you could easily support a large number of concurrent users (e.g. 1000) using only 512MB JVM memory, you can just as easily make huge memory demands from a single user by running XML or Excel based reports/imports, as these require in-memory workspace handling and so much of the peak memory use corresponds to large report tasks. On a positive note, reports which direct output to CSV or HTML place very small memory demands on the system. A fully functioning machine with 2000 concurrent users will generally need about 8GB physical RAM (assuming all services such as the database server and application server) are on the same machine). It is rare for a single instance of EKP to itself exceed 1GB (with 2000 concurrent users) even when very heavily loaded, largely due to the way in which it manages its cache, but you can certainly benefit from additional system RAM to facilitate more OS, database, and web server caching, as these processes are independent of the EKP resource allocations. A typical EKP instance running 300 concurrent users will require about 500MB. So, for a single machine with a single instance of EKP, the database, JVM, and web server, 4.0 GB of physical RAM should be adequate for light to medium workloads ( concurrent users). If running multiple instances on the same machine, this figure would of course need to be adjusted upwards accordingly. EKP directly manages a heavily optimized cache of LMS objects in order to reduce database activity, and if properly configured, this can have a major impact on performance. In order to enable EKP to use memory adequately, it is important that the JVM memory allocation (set via regedit parameters), and the ekp.properties cache setting are appropriately set. Some sites have massive physical memory that is unused because the memory has not been assigned appropriately, and the application can be starved for resources even while lots of free RAM exists. Configuring these setting properly are covered in the EKP Installation Guide.

12 Enterprise Knowledge Platform Capacity Planning Guidelines Page 9 For a hosting service it is common to run multiple EKP instances on the same machine. This is a more complex hardware configuration calculation as there are multiple ways in which such a server can be configured, but the memory requirements for each instance of EKP are additive, as they are most often configured as completely independent instances/jvms that share the same web server and the same database. We have a demo machine with 4GB ram that is running ten independent, small demo/test sites (with shared Apache web server and shared Microsoft SQL Server database) with no problems.

13 Enterprise Knowledge Platform Capacity Planning Guidelines Page 10 Getting Statistics From Live Systems One of the strengths of EKP is the wealth of operational information available regarding real-time performance. It is strongly recommended that an operational system make use of this information to determine the characteristics of the workload for a given site, and to conduct performance tuning based on this information. Even a properly configured server will be struggling if various system and application parameters are improperly configured. Within EKP, the System Statistics area provides the following key measures that help in evaluating system performance: System Activity Statistics, which outline the summary level usage patterns for your site. These statistics are broken down into broad categories such as # of enrollments, max # of concurrent users, etc. Transaction Execution Statistics, which provides detailed execution response time measures for each type of transaction request submitted to the system. This helps to indicate where bottlenecks may be

14 Enterprise Knowledge Platform Capacity Planning Guidelines Page 11 developing, and where users are experiencing slow response time. Database Connection Statistics, which indicates how connections are being used, whether there are too few allocated, etc. Cache Statistics, which provides hit rate information for the various object caches used by the system. If insufficient memory is allocated, this information will indicate poor hit rates. Ping, to provide basic network turn-around time measures so that you can isolate response time problems. Page Size Statistics, which is a detailed accounting of the average/max HTML page sizes returned by each EKP transaction. HACP Command Execution Statistics, which provides execution overhead details for course tracking requests, helping to isolate problematic courses or command handling. It is beyond the scope of this document to cover all aspects of data analysis and tuning, so the reader is referred to the EKP Operations and Troubleshooting Guide for additional guidance regarding configuration and tuning of production systems.

15 Enterprise Knowledge Platform Capacity Planning Guidelines Page 12 Rule-of-Thumb Base Guidelines The following guidelines may be used when configuring a new production system where there is a lack of detail regarding user usage patterns, courseware types, and other typical technical attributes upon which these decisions are usually based. Important Note These rule-of-thumb figures represent estimations of likely systems based on measurements from live production sites, and of course these estimates gloss over numerous technical variations between sites. For example, your site s workload (number of concurrent users), types of course (media types, size, tracking requirements, etc.), degree and frequency of reporting, hours of operation) will vary from the average upon which these figures are based. However, we understand that it is common to NOT have these details at the beginning of a project, hence these real-world based guidelines discussed below are otherwise the most accurate and practical way to estimate future system requirements. Base System: Intel 2.4Ghz dual-core CPU or equivalent 2GB RAM Minimum RAID-5 Disks EKP Requirements: For each 500 concurrent users, add another 2-core 2Ghz CPU; this assumes that there will be approximately 500 peak concurrent users per 10,000 in the database this figure is consistent will actual production systems, where actual loads range from 1% to 5% (at peak) of the total user population. Note that all communities of users are not necessarily active at the same time, so it is not appropriate to base the workload solely on the total population of users if the users are distributed geographically and by timezones. For each 100 on-line courses, add 2GB Disk;

16 Enterprise Knowledge Platform Capacity Planning Guidelines Page 13 For each 10,000 users, add 1GB disk space per year for database records; Approximately 256MB additional RAM per 10,000 users If the database server is on the same machine, add 2GB Of course, these guidelines are simplistic as there are also some minimum memory usage considerations, no matter what the user population happens to be, so keep this is mind when preparing a final configuration.

17 Enterprise Knowledge Platform Capacity Planning Guidelines Page 14 General Systems Environment Examples Assume 15GB for basic system software (OS, Database, web server, Java run-time) Assume 50% free space for general expansion, work areas, etc. Example 1 A system supporting 5,000 users probably should be configured with: Dual-core CPU or better 4GB Ram Database initially sized to 2GB RAID5 or mirrored disk as required (50GB is typically adequate for 1000 courses and three years worth of database growth). The system should also have at least another 50GB of free storage available for growth/working space. Important Note Regarding disk space configurations: Retail disk capacities are growing at a very rapid rate, as are the media requirements for new course types, hence it is always good to oversize the expected disk configuration to cater for future unanticipated storage needs. Example 2 A system supporting 50,000 users should be configured with: Quad-core CPU 8GB Ram Database initially sized to 10GB RAID5 or mirrored disk as required (50GB is typically adequate for 1000 courses and three years worth of database growth). The system should also have at least another 50GB of free storage available for growth/working space.

18 Enterprise Knowledge Platform Capacity Planning Guidelines Page 15 Example 3 A system supporting 200,000 users should be configured with: Two Quad-core CPUs 16GB Ram Database initially sized to 20GB RAID5 or mirrored disk as required (60GB is typically adequate for 1000 courses and three years worth of database growth). The system should also have at least another 60GB of free storage available for growth/working space. Example 4 A system supporting 500,000 users requires a more complex analysis than is covered in this particular paper, and would be best served as a cluster configuration of five machines organized as follows: One quad-core (8GB RAM) CPU Database Machine Three dual-core (4GB RAM each) CPU Application Servers Evaluate need for multiple content servers One Load Balancer Machine Database initially sized to 30GB RAID5 or mirrored disk as required. More information on load balancing configurations is covered in the paper EKP Multiple Instance Configuration and Load Balancing. Note Systems often experience network bandwidth constraints before running into server performance problems, so these general recommendations should always be considered in the context of overall workload and infrastructure requirements. Bandwidth requirements are very much dependent upon dispersion of users, course size, concurrent user load and usage patterns, etc. For these situations, and analysis of multiple Content Server placement to distribute courseware around a network to reduce bandwidth bottlenecks is also recommended.

19 Enterprise Knowledge Platform Capacity Planning Guidelines Page 16 Typical Client Configurations The following configurations are currently in production at the NetDimensions hosting service and at client sites. These configurations are intended to illustrate working configurations, but as each site has different processing profiles, it should be used only as an indication of what works under certain conditions in the real world. Finance Industry Server HP, Windows Server 2003 EKP Version 5.5 CPU Two Quad-core CPUs Disk 500GB RAID5 Ram 16GB Web Software Apache/Tomcat 5.5 Database Size Microsoft SQL Server 2005: 15GB Operations 24x7 # Users 200,000 # Courses 25,000 Course types Online and classroom # years in production 5 Avg # Concurrent users 500 daytime, 1200 nighttime Avg CPU Usage: 10-20%

20 Enterprise Knowledge Platform Capacity Planning Guidelines Page 17 Airline Industry Server Sun E450 Solaris EKP Version 5.0 CPU 4x400Mhz Disk 4x18GB RAID5 Ram 4GB Database Size Oracle 10g: 10GB Web Software: Apache/Tomcat Operations 24x7 # Users 21,000 # Courses 5000 Course types Online, Classroom, Virtual Classroom # years in production 5 Avg # Concurrent users 250 Avg. CPU Usage: Info Not Available Finance Industry Server Dell, Windows 2003 EKP Version 4.7 CPU Dual-core Disk 200GB RAID5 Ram 4GB Web Software IIS/Jrun Database Size Microsoft SQL Server 2005: 2GB Operations 24x7 # Users 37,000+ # Courses 700 Course types Online # years in production 3 Avg # Concurrent users 300 Avg CPU Usage: Info Not Available

21 Enterprise Knowledge Platform Capacity Planning Guidelines Page 18 Internal Benchmark System Example Overview The following sections illustrate the measurements taken from systems used in an internally conducted benchmark exercise where the emphasis was on testing pure EKP activity (as opposed to courseware handling which puts minimal strain on the server as the courseware typically runs as an applet or plugin in the client). Important Note Generally speaking, live systems have a high percentage (e.g. 75%) of the concurrent users taking courses rather than navigating through EKP functions. This is significant as courseware activity is MUCH less resource intensive (typically only 5-10% of the overall server load) when compared to EKP functions (e.g. transcript review, reporting, etc.) as courseware activity is principally browser download activity/bandwidth oriented, whereas EKP function activity is server CPU and database intensive. The benchmarks shown in this section assume 100% EKP user activity, hence this represents a worst-case scenario for on-line activity impact on the server. Interpreting Benchmark Data As a general rule, we discourage people from using benchmarking statistics for sizing purposes. Why? Because synthetic benchmark profiles almost never match your real world workloads as they as geared towards specific function tests, and as such it is useless as a guide for your sizing purposes. We strongly recommend comparisons to actual production site measurements as a more practical guide -- the guidelines provided in the first section of this document should be used. At NetDimensions, these synthetic benchmarks are useful to us since we can compare activity on specific functions from release-to-release, and we can use the test drivers to place the system into overload (e.g. stress testing with 100,000 concurrent users) to determine where bottlenecks occur. So, for engineering purposes this is very valuable information, but for general sizing

22 Enterprise Knowledge Platform Capacity Planning Guidelines Page 19 it is irrelevant when taken out of context. We have included some sample data here so that you have an idea of what types of information are available. Testbed Testbed Hardware Database Server Configuration Host Name CPU Physical RAM Disks TEST1 Intel Pentium 4 (2.0GHz) 512MB 40Gb WebServer/EKP Server Configuration Host Name CPU Physical RAM Disks TEST2 Intel Pentium 4 (2.0GHz) 512MB 40Gb Test Driver Configuration Host Name CPU Physical RAM Disks TEST3 Intel Pentium 4 (2.0GHz) 512MB 40Gb

23 Enterprise Knowledge Platform Capacity Planning Guidelines Page 20 Testbed Software Software Product Web Server Apache HTTP Server v Servlet Container Jakarta Tomcat v4.1 Java Virtual Machine SUN JRE v1.3.1 (Server JVM) Learning Management EKP 3.0 System Database (RDBMS) Microsoft SQL Server 2000 v (SP2) Operating System Microsoft Windows 2000 Server with SP4 Load Testing Radview Webload v4.6

24 Enterprise Knowledge Platform Capacity Planning Guidelines Page 21 Performance Measurements The following load tests were performed with Grinder for 10 minutes, run in a closed intranet environment. The statistics are captured by Grinder monitors, Windows NT Performance Monitor, and by EKP internal tracking systems. The simulated environment was setup as a 2-tier system: Web/Application Tier and Database Tier for maximum performance. All authentications are performed by EKP internal authentication module (as opposed to the LDAP external authentication adapter).

25 Enterprise Knowledge Platform Capacity Planning Guidelines Page 22 Web Tier Setup The Web and Application Servers were installed on a machine named TEST1 Apache HTTP Server 1.3 Settings (Web Server) Parameter Server Host Start as Value TEST1 Windows Service Apache Jakarta Tomcat 4.1 Settings (Servlet Container) Parameter Start as JVM minimum/maximum memory allocated (-ms / -mx) Value Standalone -ms100m mx512m NetDimensions EKP 3.0 Settings (LMS) Parameter Database Connection Pool Initial Size Database Connection Pool Maximum Size Database Connection Pool Incremental Size Value

26 Enterprise Knowledge Platform Capacity Planning Guidelines Page 23 Database Setup The Database Server (RDBMS) is installed on TEST2 Microsoft SQL Server 2000 with SP2 Parameter Server Host Start as Memory Memory (Minimum) Memory (Maximum) Processor Maximum Worker Threads Boost SQL Server priority on Windows Use Windows NT Fibers Value TEST1 Windows Service Dynamically Configured 0 MB 512 MB (machine maximum) 255 Yes No

27 Enterprise Knowledge Platform Capacity Planning Guidelines Page 24 Load Script A sample user workload script with mixed transactions was used. Here is a summary of the script functions, with the emphasis being on EKP transactions that require database access. A real-world transactions mix typically has only a small amount of database access required, as many screen are menus and a large percentage of the user s time is spent in the course (which provides minimal load to EKP), so this mix is MUCH more stressful on the server than real-world workloads. Major Transactions Used: EKP TX Code LOGIN SEARCHRESULT CATINTRO GETPEERCOMM GETARTICLE GETMSG LISTTRAN LISTSESSIONS LISTPUBLICNEWS TOCPERSONAL LISTCERTS LEARNINGSPACE Description Login Authentication Search Learning Objects from Catalog Retrieve Catalog Retrieve Peer Comments on Learning Objects Retrieve a news article Retrieve private internal message Retrieve personal transactions Retrieve Sessions of Learning Objects Retrieve Public News Retrieve Personal Profile Retrieve Personal Certifications Launch Personal Learning Space Script Parameters Think time Random unique User IDs picked from user population 5000 milliseconds (5 seconds) 250

28 Enterprise Knowledge Platform Capacity Planning Guidelines Page 25 Processor Usage (Percentage) Concurrent Users Users in database TEST1 (Avg.%) TEST2 (Avg.%) As can be seen from these figures, a 2.0Ghz CPU is inadequate for 1,000 concurrent users, hence this particular configuration under test should be limited to 500 concurrent users. A configuration for users should employ an SMP solution, or a cluster configuration with the EKP workload distributed across multiple machines (see EKP Multiple Instance Configuration and Load Balancing Guide for more information on such a setup.)

29 Enterprise Knowledge Platform Capacity Planning Guidelines Page 26 Memory Utilization Concurrent Users Users in database TEST1 (MB) TEST2 (MB) Note here that memory on the database machine (TEST2) is fairly constant as a fixed buffer cache size is used. Memory on TEST1 grows as the Java Virtual Machine allocates more memory to cope with EKP internal object caching demands. The EKP User Object cache size was set to 1500 for all tests.

30 Enterprise Knowledge Platform Capacity Planning Guidelines Page 27 Transaction Statistics Concurrent Users # Users in database TX Count Total Time (ms) Average Time (ms) , , , , , ,815, ,377, ,201, ,671, ,581, ,727,

31 Enterprise Knowledge Platform Capacity Planning Guidelines Page 28 Disk Size Planning Database Size SQL Server 2000 Data Files and Transaction Logs should be configured to Automatically grow file. With a stable system, 10% percentage growth should be sufficient in most cases. Assuming that the column of the tables are fully packed, the following are estimates of table sizes of USERS, LEARNINGOBJECTS, COURSES and TRANSCRIPTS for a database with 10,000 users, 2000 learning objects and 5 transcripts per user. Table Number Size of Number of Total Total of Size of the of a records / of Extensions table (in records record page Pages kb) USERS , , ,032 LEARNINGOBJECT , ,698 COURSE , ,032 TRANSCRIPT , ,072 TOTAL 45,834 The following are estimates of table sizes of USERS, LEARNINGOBJECTS, COURSES and TRANSCRIPTS for a database with 100,000 users, 5,000 learning objects and 5 transcripts per user. Table Number Size of Number of Total Total of Size of the of a records / of Extensions table (in records record page Pages kb) USERS 100,000 1, ,000 3, ,000 LEARNINGOBJECT , ,698 COURSE , ,032 TRANSCRIPT , ,802

32 Enterprise Knowledge Platform Capacity Planning Guidelines Page 29 Yearly Growth Rate For example, to calculate the disk requirement for the following: 1000 new users per year 100 courses/modules per year Each new user takes 100 courses per year Additional database disk space requires is: (1000 * 1.6KB) + (100 * (1.3KB + 1.7KB)) + (1000 * 100 * 0.4KB) = 101,105KB So, the yearly growth rate requires about 102 MB. Database Sizing Recommendation The figures used for the above calculations assume a fairly worst case usage scenario, but it is safe to assume that a SQL Server database for 10,000 users should initially be configured for 1.0GB (with expansion to 2GB to cater for expected (and unexpected) growth over the following three years). Log Size On even a busy server, the quantity of information stored in the log files is moderate by RDBMS application standards (there is a high percentage of read-only activity in an LMS, which does not contribute to log space growth). It is recommended that the log file size should be at least 20% the size of the data files.