IBM R5, pSeries Lotus Domino Server R5 User Manual

202.07 Kb

Revised: June 18, 2001

IBM® ^pSeries Solution Series for e-business

Lotus® DominoServer R5

Implementation Guide

Page 1

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Table of Contents

pSeries Lotus Domino Server e-business Solution Overview . . . . . . Page 3

Supported Software Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 5 PTF Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 6 Performance Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 7 Sizing Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 13 Sample Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 17 Pre-installation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 18 Implementation Process Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 20 Checklist for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 32 Installation Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 33 Post-installation Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 40 Services Available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 42 Additional Technical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Page 43

Appendix A. Sample Configurator Configurations . . . . . . . . . . . . . . . . . . Page 45 Appendix B. IBM Production Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . Page 53


This solution was created and tested under laboratory conditions. Although all material is correct at date of creation, production environments may require additional steps, configurations, and performance analysis. The material herein is provided on a best-effort basis and the certification of the solution rests on the implementation team. This information is intended to guide the implementation team with initial findings for IBM Solution Series for e-business - Lotus Domino Server R5. This guide has no implied warrantee nor guarantee. The users of this guide should always check the latest release information in the product Readme file(s) and check the product Web pages for the latest updates and findings.

The following terms are trademarks or registered trademarks of the IBM Corporation in the United States or other countries or both:


DB2 Universal Database e-business

IBM Redbooks RS/6000 SmoothStart

The following terms are trademarks or registered trademarks of the Lotus Development Corporation in the United States, other countries, or both: Domino, Domino.Doc, NotesBench, Lotus Notes, Notes, and Passport Advantage.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks or registered trademarks of Microsoft Corporation in the United States, other countries, or both.

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both.

UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company Limited.

All other registered trademarks and trademarks are the products of their respective companies.

Page 2

Lotus Domino Server R5 Implementation Guide

June 18, 2001



pSeries Lotus Domino Server e-business Solution Overview

Domino, a server-based product from Lotus® Corporation of IBM®, is positioned in the e-business™ marketplace as a messaging/groupware system with dynamic application serving. Domino's integrated application services, such as security, workflow and content management, optimize the platform for rapid delivery of Web applications, along with built-in connection services that provide live access to relational databases, transaction systems and ERP applications. By using Internet standards, Domino avails itself to browser clients and Internet protocols, as opposed to proprietary clients and protocols.

The Domino R5 family of servers delivers messaging, applications, and online collaboration fast and reliably for organizations from small businesses to the largest enterprises. Domino R5 helps reduce costs by making the server easier to administer and the desktop easier to manage.

First and foremost, Lotus Domino is a messaging system. It contains E-mail creation and delivery capabilities along with directories of people and objects with multiple levels of security from encryption to ACLs. Domino offers the industry's most comprehensive support for Internet messaging standards, with Internet addressing, SMTP routing and MIME content support, plus full support for E/SMTP, S/MIME, SSL, POP3, IMAP4, LDAP, HTTP, HTML, and SNMP.

The directory function of Domino contains names, addresses, and distribution lists. High-speed lookup capabilities utilize compressed directories that can be stored on local client disks. Most of the advanced functions of E-mail are included in Domino, such as encryption, tracing, format translations, attachments, and logging.

Domino contains a full calendaring and scheduling function that provides free-time searches, sending of meeting notices, time zone support, Internet access, security, and attachment capabilities. Migration aids are available to migrate non-Domino calendars to the Domino server.

Workflow is a rules-based “development” capability that combines programming logic (using templates) with mail and directory information. This allows companies to achieve efficiencies in applications such as travel expense approval, document reviews, and selective distribution of information.

Another element of collaboration is the sharing of data and documents. Domino contains a database where all information of any object type is stored. Data in the database can be assigned various levels of sharing from “none”, to password-controlled, to group-controlled, to author-controlled, to encrypted, to full access to everyone. The level of control is defined by either the administrators or authors of the document. With the ability to share data, Domino provides workgroup efficiency.

If a complete document management system is needed, Lotus offers an extension product called Domino.Doc. Domino.Doc uses a familiar library metaphor of file rooms, file cabinets, and binders. It supports complete document life-cycle management from authoring through review, approval, distribution and archiving. Domino.Doc also provides version control and check in/check out capabilities.

To support overall system performance, Domino provides a database facility called replication. Using replication, multiple servers and/or clients can have a copy of the database that “copies” itself whenever any item in the database changes, or it can be “copied” at defined intervals, or on demand. Having local copies that are always up-to-date provides better access time, allowing clients to work in standalone mode.

Domino creates applications with data and logic, stores them in the Domino database, and provides dynamic translation to users so that they can run the applications from either a browser or a Lotus Notes client interface. Domino’s application development tools support the use of wizards, templates, C++, or Java.

Applications can range from simple views of data with update capabilities, such as providing catalog information, to sophisticated applications such as inventory management, billing, and process models. Domino’s tools and programming interfaces allow for searching, access, and inclusion of data in enterprise relational databases such as DB2® Universal Database and Oracle®. The possibilities are further extended through the use of Domino Connectors and Lotus extension products available on AIX such as Lotus Enterprise Integrator (LEI), Lotus Domino Workflow, and Lotus Enterprise Solution Builder.

Page 3

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Domino is a generic name for a family of server products: Domino Mail Server for mail, groupware, calendaring and Internet support functions; Domino Application Server for mail plus application development capabilities; and Domino Enterprise Server which adds partitioning, clustering, and usage tracking capabilities on top of Domino Application Server.

Domino supports a wide variety of popular clients, including Lotus Notes clients as well as Web browsers, Microsoft Outlook®, and mail clients based on Internet standards such as POP3 and IMAP4. Full function Notes R5 clients for messaging and/or collaboration run on Windows® 95, 98, 2000, and Windows NT® 4.0 workstations, as well as Macintosh® computers running Mac OS 9.

The latest release of Domino is R5 and contains the following advancements over Domino R4:

1.Native Internet format for mail including SMTP and MIME

2.Built-in upgrade tools for migration from applications such as cc:Mail and Microsoft® Exchange

3.Wide choice of supported clients such as Notes clients, browsers, Eudora®, and Outlook

4.Built-in connectivity for live access to relational databases and transaction systems

5.New simplified deployment and administration tools

6.Choice of Internet authoring tools for HTML, JAVA, IDE’s, and scripting

7.Improved failover supporting browers, as well as Notes clients

8.Dynamic load balancing

9.Improved capacity of directories with corresponding improvement for mobile users

10.Higher performance due to database redesign

11.Optimized to AIX® for improved capacity and response time

Page 4

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Supported Software Releases

Domino Server R5 is supported on the following versions of AIX:

Domino Release

AIX Release

Domino Server R5






Page 5

Lotus Domino Server R5 Implementation Guide

June 18, 2001



PTF Matrix

In order to install Domino Server R5 on AIX, certain program temporary fixes (PTFs) are required or specific authorized program analysis reports (APARs) should be read. The following table lists the patch requirements:


Recommended Level








































Needed to prevent crashing of



server when running NSD



Prevents a problem where client



connections are never released



Maintenance level 8 (APAR


IY10778) and microcode MM1032



required to enable HMT



Page 6

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Performance Guidelines

Disclaimer: Performance of applications can only be made in a general sense. Specific characteristics of application implementation on specific hardware will yield different performance characteristics. Performance tools for measurement and tuning exist in most instances and should be used.

The Domino Server Family has had success in the market due in part to the functionality it provides for messaging, groupware, and Web application development. Because these advanced and varied sets of capabilities are integrated into one platform, measuring the performance of the Domino Server and providing recommendations for specific customer environments always proves a challenge.

A. What Affects Application Responsiveness?

In today's distributed client/server environments, the elements that affect your customers’ experience of application responsiveness are highly variable. A sophisticated application deployment tool and messaging platform like Lotus Domino has many factors that can impact its performance:

ŸNumber of users

ŸUser tasks and workload mix

ŸAccess to back-end relational databases

ŸStatic versus dynamic Web pages

ŸRobust graphical displays based on Java and ActiveX

ŸClient type (simple browser, advanced unified clients like Active Desktop, Lotus Notes)

ŸUse of mail hubs

ŸRS/6000® configuration

ŸNetwork protocol and access methods

ŸServer deployment topology

Network Protocols and Topology

Your network protocols also have an impact on your network's performance. TCP/IP has historically proven to provide the best performance and most efficient use of network adapter hardware for Notes and Domino environments. We highly recommend that you use TCP/IP on your LAN if possible, especially when implementing a geographically dispersed network that utilizes WAN links. This is because most routers use TCP/IP to communicate over WAN links, so using it on the LAN reduces processing overhead.

The partitioning and clustering features of the Domino for AIX Enterprise Server do not support the IPX/SPX protocol. In addition, support for the maximum number of client sessions can only be accomplished with TCP/IP. SPX and SPX II protocol support is intended for migration from the IPX/SPX environment

Network Topology

Your Domino infrastructure's overall scalability depends in part on how much traffic your network can route and process efficiently. For example, if you initially deploy a few servers in a peer-to-peer topology, you may need to switch to a hub-and-spoke configuration as you add servers.

In an existing, large-scale deployment, make sure that your hub servers aren't overloaded. Check whether configuring servers-by-function for mail and replication would makes sense. Ultimately, you may be able to significantly boost mail throughput and application server bandwidth by upgrading just a few servers.

Page 7

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Other Workload Factors

Other factors that can impact the actual load that a given user community places on a Domino server include:

ŸThe extra overhead associated with a significant number of dial-up connections, such as mobile employees getting E-mail or suppliers accessing a supply chain automation application.

ŸThe extent to which applications access back-end data like relational databases and transaction monitor systems. As you might expect, the greater the number of network layers and connections involved, the greater the overhead.

ŸThe design of your applications. For guidelines on how to design efficient Web and intranet applications, see the Lotus white paper Maximizing Application and Server Performance in Domino

(January, 1999).

B. Steps to Maximum Domino Performance

Performance monitoring and analysis tells you whether a server is up to the strain you're putting on it, or whether it's cracking under pressure. It can also help you find the limiting factor in a server configuration, as well as a bottleneck elsewhere in your network.

Monitoring and analyzing server performance is not easy. It can seem like more trouble than it's worth at times. But there simply is no substitute for it; in the long run, it will save you far more time and money than it costs. And you'll improve your network's efficiency and reliability in the bargain.

One key piece of advice transcends all others: Keep a "holistic" perspective on the process. Likely pitfalls in performance analysis are:

ŸBasing your analysis on a single performance metric.

ŸLooking for a single step that will solve all your problems. Factors that impact performance are interrelated. So there's almost always more than one move you'll need to make.

ŸMaking across-the-board decisions or recommendations. Each server or platform has unique workload characteristics, related to the databases on the server and what users are doing with them. These differences can be important.

Know the Configuration

Domino administrators should know the configuration of the servers they're supporting. The main components of any server are memory, CPU, and disk (both logical and physical). Things like onboard cache memory and the number of disk controllers are also important.

Here are additional tips that may help you find configuration-related problems faster:

ŸUse the fastest disks you can find (10,000 RPMs).

ŸUse hardware RAID over software RAID; it's faster and there's less CPU overhead.

ŸProcessor speed is important for indexing.

ŸAn adequate disk subsystem means lower memory requirements because fewer temporary I/O buffers are cluttering up your RAM.

ŸBeware of standard server configurations; they are not optimal for Domino servers. The most important thing missing is typically adequate disks and controllers. See your hardware vendor's NotesBench® data for guidelines. (In other words, configure your systems like the folks who ran the NotesBench tests configured theirs.) For more information, visit (registration required).

Page 8

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Distribute I/O Across Physical Disks

Our experience has shown that physical and logical disk structures are our customers' least understood system resource, and the one most often undersized. The best way to boost performance on many Domino servers is to distribute I/O across separate physical disk subsystems.

Ideally, you want to put the following I/O-intensive files on separate physical disks:

ŸThe Notes paging file

ŸYour .NSF files

ŸThe Domino R5 transaction log

If you can put them on separate controllers, too, so much the better. The idea is to increase I/O throughput by distributing the work over busses, controllers, ports, and disks. Hence, several small physical disks are better than a few large-capacity disks. In particular, the more you isolate the R5 transaction log from other disk activity, the better your server performance will be.

Log Performance Metrics Consistently

If you don't log performance metrics, you won't be able to quantify the success or failure of your tuning efforts. If you do keep logs, you'll not only have a far better idea of what you're doing, you'll have a far easier time documenting the need for additional expenditures.

Among the key metrics to track are:

ŸTotal CPU utilization (expressed as a percentage). If this metric is above 70% to 80%, that's a red flag.

ŸDisk queue length (typically this should be less than 2 items in the queue) and average disk service time (should be less than 70%).

ŸPaging file size and utilization. Utilization should be fairly low, or it's probably worth it to buy more memory

ŸDomino statistics and events for mail throughput, replication, Web server activity, and database activity.

ŸDomino logs (log.nsf); they're boring but they often come in handy.

It's important to collect production data weekly, and analyze it monthly if possible. It's also critical to capture "snapshots" of performance before and after major configuration changes.

For AIX systems, there is a Notes Agent for Performance Toolbox (PTX) that will monitor and report on Domino Performance.

Optimize for Domino R5

Domino R5 does a great job auto-configuring and dynamically reconfiguring key parameters for maximum performance. Here are some tips from the experts on how to tune the Domino R5 server itself:

ŸSet up the correct number of mailboxes. Multiple files reduce contention for mail deposits and other mail-related activity. The biggest performance gains come when you add a second mailbox. The rule of thumb we use is one mailbox for 1-200 users supported, two or more for 200-1,000 and ten (the maximum) for 1,000 or more users.

ŸFor non-partitioned systems, let Domino dynamically set NSF_Buffer_Pool_Size. This is particularly important in low memory server configurations, where a large buffer pool can interfere with the kernel's memory management.

Page 9

Lotus Domino Server R5 Implementation Guide

June 18, 2001



ŸFor partitioned systems, you will need to ensure the NSF Buffer Pool is properly set since Domino cannot automatically determine the memory that’s actually available to it across multiple partitions. This can be accomplished by placing the following variable in the notes.ini file:

PercentAvailSysResources=nn (where nn is 100 / number of partitions)

ŸLet Domino allocate mail delivery threads (for local delivery) as needed, based on available memory.

ŸLet the Domino router allocate the mail transfer threads (for delivery to another server), based on demand.

Configured appropriately, a Domino R5 server running on AIX can transfer 20,000 messages in one minute.

Make Use of NotesBench Data

Most benchmarks just tell you what vendors want you to hear. But NotesBench really is different. NotesBench benchmarks enable you to make "apples to apples" comparisons about Domino capacity on hardware configurations from various vendors. You can even guesstimate total cost of ownership with reasonable accuracy using these numbers.

Perusing NotesBench data is also a great way to glean information on how to optimize your system configurations. Check out what disk topology, kernel settings, patches, and service packs were used (and not used) to squeeze maximum performance from their systems.

Learn from Semaphores

Semaphores are a communication mechanism used among process threads. Here is a list of popular semaphores and what they mean from the standpoint of performance:

ŸCollection (0x30B) and Collection Queue (0x309). Indicates that the CPU and memory are bottlenecked. Best fix is to defer Administration Process activities to non-peak hours and optimize the I/O subsystem.

ŸDB (0x245) and DB Queue (0x244). Indicates that the database cache and disk I/O are bottlenecked. Best fix is to add more memory and optimize the I/O subsystem. Enabling field-level replication (if you haven't already) will also help.

ŸBTree (0x255). Indicates a problem with how views are stored and rebuilt. The best fix is to defer view rebuilding to off-hours, and optimize the I/O subsystem.

Know the Symptoms of Server Over-Utilization

Typical problems that point to a server that's in over its head are slow or failure-prone mail delivery, degrading user response time, and slow address lookups.

To check mail delivery, look at the percentage of time your disks are utilized, and at mail queue length. For R5, you can also check (and optimize) the number of files and the numbers of transfer and local delivery threads.

To enhance response times, try optimizing the manner in which I/O-intensive files are distributed across the disk subsystem.

If address lookups are slow, things may improve substantially when users deploy Lightweight Directories on their desktops. This will reduce the load on the server and the network. You can also check the hit rate for the Name Lookup Cache. A good hit rate is at least 85%.

If your problem is slow page rendering or an unresponsive Web server, check the number of HTTP threads, and the percentage of time disks are utilized. Set the number of HTTP threads at 1:10 (one thread for every ten users).

How can you tell if a server is underutilized? Look for a CPU utilization rate below 50%, disk access ratio below 50%, or more than 200 MB of RAM consistently available. But note that the resources required for

Page 10

Lotus Domino Server R5 Implementation Guide

June 18, 2001



additional users probably won't be equivalent to the resources required for an equal number of your current users. For example, per-user memory requirements decrease as the number of users increases, because fixed memory overhead is divided across more users.

Consider Clustering

Clustering is the premier feature of the Domino Enterprise Server. Clustering gives you dynamic load balancing, which automatically optimizes resource utilization across the cluster. Clustering also provides failover for mail and applications, including Web applications. You can cluster any combination of R4 and R5 servers, across any mix of supported Domino platforms. And you can cluster partitioned servers alongside non-partitioned servers.

Consider Partitioning

Partitioning can improve the resource utilization of high-end Domino systems, however, it may also require additional hardware resources to properly implement transaction logging. It allows you to distribute servers by department or function while retaining the benefits of consolidation. Some organizations even use partitioning to create "service level options" (i.e., putting a few key executives on one partition and the masses on another). As a general rule, the number of partitions on a system should never exceed the number of CPUs.

Know When to Consolidate and When to Distribute

Unless you have some compelling reason to do otherwise, choose consolidation over distribution as a growth strategy. Consolidation invariably reduces cost and improves reliability: fewer servers mean less complex server topologies, and fewer server-to-server activities: less network traffic, less replication, and less mail transmitted between servers.

When would you want to distribute servers instead of consolidating them? You may have geographic distribution requirements where dedicated servers handling local users and data are the lowest-cost solution. Or your deployment may be comparatively small but growing fast, so adding more servers to accommodate new users or distribute functions lets you leverage current investments better. IBM has developed a Red Book on this subject, entitled IBM Servers and Lotus Domino: Centralize and Distribute Enterprise Architecture Planning, available at

C. Performance and Capacity Planning Tools and Resources from Lotus

To help you appropriately plan for your deployment, Lotus provides:

ŸTools and benchmarks from Lotus and RS/6000 that enable you to monitor, manage, and optimize Domino Server performance.

ŸSupport resources that help you address the performance in your environment.

ŸKnowledge transfer in the form of course packs and online resources to help you understand the issues involved.

ŸDomino Performance, Capacity Planning, and High Availability Web site that provides current detailed information about performance and capacity planning, tools, hardware benchmarks, white papers, and interactive discussion forums. Visit for more information.

Lotus NotesBench

Lotus and RS/6000 use NotesBench, a standard benchmark for Domino, to generate and provide performance information. NotesBench uses standardized workloads with a strict testing protocol on various Domino/Notes platforms and configurations.

Customers can, in turn, use the benchmark information while evaluating RS/6000 and pSeries models, selecting configurations, and planning against resource budgets. Business Partners who are members of the NotesBench Consortium, and have been trained in the use of NotesBench tools can create

Page 11

Lotus Domino Server R5 Implementation Guide

June 18, 2001



specialized benchmarks that are unique to a customer’s deployment. This allows Business Partners to assess specific server environments and compare it with various RS/6000 models and configurations.

An independent agency audits and published NotesBench reports. For the latest information and NotesBench reports, see or

The NotesBench Mail workload models an active user reading and sending mail, along with the additional functions of user lookup, creating a meeting invitation (every 90 minutes), etc. Overall, the workload is still seen as very light.

As a rule of thumb, if you divide the NotesBench users attained by 3 or 4 or 5 you may be close to an approximate number of “real” users. If calendar functions are used, up to an additional 25% reduction in the number of “real” users is a good rule of thumb.

NotesBench Metrics

Lotus NotesBench is a collection of benchmarks, or workloads, for evaluating the performance of Domino servers. Of particular interest are:

ŸMaximum users supported: The maximum number of concurrent workload threads connected to the server during the simulation.

ŸNotesMark: A throughput metric, which measures performance in terms of the cumulative number of Notes transactions per minute (tpm) performed by all the threads in the test. Note that tpms do not correspond 1-to-1 to Notes operations; opening a database, for example, is one transaction from a real user's perspective, but may constitute two or three transactions from the viewpoint of NotesMark.

The following mail workload scenarios were driven by an automated environment which ran a script similar to the mail workload from Lotus NotesBench. Some of the results shown here are not official NotesBench measurements or results and are noted as such. Unofficial numbers may not be used officially or publicly to compare to NotesBench results published for other Notes server environments. For official audited NotesBench results, see (Note: In order to access the NotesBench results, you will need to apply for a userid and password through the NotesBench organization.)








Mail Users







per minute)





RS/6000 Enterprise







Server M80







8-way, 4 partitions







RS/6000 Enterprise







Server F80







6-way, 2 partitions







RS/6000 Enterprise







Server S80







24-way, 24 partitions







pSeries 640 - B80







4-way, 7 partitions(1)







pSeries 680 - S85







24-way, 30 partitions(1)







1. The results are not official NotesBench measurements or results.

Page 12

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Sizing Guidelines

Disclaimer: System sizing for applications can only be described from a general perspective. Definitive characteristics of application implementation and behavior on specific hardware will yield different sizing requirements. Use system sizing tools when available for your specific environment.

Domino on AIX:

Several factors should be considered when determining the size of the hardware for use with Domino Server. Among these are number of users, network topology, geographic locations, and scalability. Since every installation of Domino Server is different, there is no way to give an exact measurement for determining the size of the hardware needed to support a population of users. The information provided here is a “rule of thumb” and provides a good starting point for determining the size and amount of hardware required. As with any installation, the size and amount of hardware may be greater or less depending on the actual environment.

Memory requirements are a base of 128 MB of memory and 1 MB for each connected mail user anticipated on the system.

Disk space requirements are 360 MB for the Domino Server program files (160 MB for the Domino binaries and 200 MB for the data files) + 50 MB per registered mail user + additional space for any Domino application that may be used + the paging space requirements.

A good recommendation for performance that pertains to disk access time, is to split the registered mail users into separate file systems onto separate disks. A good rule of thumb to follow is approximately 500 mail files per file system.

Processor requirements are very dependent on workloads. A recent RS/6000 Model M80 benchmark had 7008 active users per partition. There is a logical limit derived from the experience of existing customers. In discussing active versus registered users, normally we apply a 50% rule of thumb; if there are 1000 registered users in the domain, then only 500 will be active at any one time. The next level of experience has to do with the complexity and quantity of mail for the registered users. We recommend running R5 across four processors. Thus, if there are to be 1000 active users, a 4-way processor with a single partition would create the best performance. The processor group used in the prior analysis was the 332 MHz 32-bit processor. As the processor speed is higher as in the S7A and S80, then the number of active users supported can grow. As the processor speed goes down to the class of the 43P-240, then the number of supported active users goes down as well.

Single processors can support Domino, but Domino will be limited by the processor power. Domino involves many processes and many threads, of which a limited number get processor time at once. To the degree that any application scales, more processors allow greater process and thread distribution, thus getting more work done at once. This is why SMP machines provide greater throughput. For example, a 2-way system would perform better with one partition of 600 active users over two partitions of 300 users each and also the environment would not have the dual administration overhead.

Network adapter requirements are 1 adapter per 1000 users. As with the processors, there are other factors that determine the number of network adapters such as user workload, Domino partitioned servers, and network infrastructure.

Page 13

Lotus Domino Server R5 Implementation Guide

June 18, 2001



A. Domino R5 on AIX

Domino R5 was designed to provide overall performance and scalability improvements over Domino R4. The table below illustrates the general magnitude of R5's scalability increase by client type:

Client Type

R5 Scalability Increase

Lotus Notes®






Web Mail

1,500% on UNIX



The above enhanced performance is due to the following changes made in Domino R5:

ŸOptimization of the database format (the On Disk Structure or ODS) to minimize I/O contention. With R5, writes to disk are fewer and more efficient.

ŸTransaction logging. In R5, database operations are recorded sequentially, not all over the disk. This reduces I/O activity levels while increasing data integrity and dramatically speeding up server re-start.

ŸMultiple server mailboxes. On a Domino R5 server, messages can be deposited into any one of multiple mailboxes. This reduces both user and router contention for mail deposits and other mail-related activity.

ŸPooling of threads relating to end-user sessions. In R5, one thread can handle sessions for thousands of users. In R4, each user session required a separate thread, and a complete memory structure to go along with it. Fewer threads and processes equals lower overhead and more available memory and CPU cycles.

ŸBetter memory management, through the Unified Buffer Manager (UBM). Among other things, the UBM dynamically manages the notorious NSF_Buffer_Pool_Size parameter, by monitoring the relationship between available memory and buffer sizes.

ŸMore efficient utilization of large memory areas. If it's available on the RS/6000 configuration, Domino R5 makes more efficient use of RAM for internal caches and buffers, boosting performance compared to storing items on disk.

ŸA two-fold improvement in the speed of view rebuilding and incremental indexing. On servers with large numbers of databases, the processing time saved is significant.

The cumulative effect of R5 performance optimizations (those listed above, plus many others) translate into efficiency gains of these rough magnitudes:

ŸA 30% reduction in memory usage requirements per user

Ÿ10-20% more efficient utilization of I/O subsystems

Ÿ75% faster response times across a broad range of mailand application-related activities

ŸSignificantly less server-to-server message traffic, resulting in reduced network bandwidth requirements

ŸTransactional logging

While R5 performance gains are generally outstanding, they are comparatively even greater on AIX. The Domino R5 architecture is so inherently scalable that it can take full advantage of the powerful RS/6000 and pSeries computing platforms, including SMPs, gigabytes of memory and terrabytes of disk.

Page 14

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Among the key Domino R5 features that enable it to scale with these platforms are:

ŸUnlimited database size (currently certified up to 64 GB), to support increased database workloads.

ŸDirectory scalability in excess of one million users, to easily handle the directory requirements of even the largest deployments. (Lotus has tested a Domino R5 Directory with 10 million entries)

ŸDatabase optimizations to better exploit high-end I/O and CPU throughput.

ŸSupport for online indexing, online database compacting, and online backup; to take advantage of high-end systems and I/O subsystems.

ŸIncreased overall scalability enabling support for more users on fewer partitions, to drive down per-user costs across large, partitioned servers.

Domino R5's ability to keep running during scheduled maintenance tasks like database compaction, indexing and backup makes server consolidation in general more attractive, since large numbers of users will not be inconvenienced due to scheduled outages.

And R5's greater scalability and new high availability features make server partitioning a more attractive alternative than ever. Partitioning yields lower total cost of ownership: administration and maintenance are simplified, and fewer moving parts increases reliability, security and availability (if one partition fails, others remain available).

Domino R5 on AIX Specifics

Domino R5 on AIX leverages many platform-specific services directly. For example, R5's new thread pooling capability was optimized specifically for AIX. And Domino R5's high-availability features are particularly well-integrated and complement those of HACMP of AIX. For example, R5's transaction logging makes performance and UNIX® auto-restart features even more effective, by allowing Domino to restart very quickly.

For customers using Domino as a Web application server on AIX, R5 clustering supports both failover and load balancing for Web clients. And the Domino R5 Server's clustering features are complementary to HACMP on AIX, such as high-speed interconnects, disaster tolerance and support for many-node clusters. In fact, Domino clustering in combination with AIX-based clustering can bring system availability into the 99.99% range.

When looking to size a Domino R5 server on AIX, the basics for memory, disk, and network adapters has not changed from R4. What has changed are the scalability factors that can be applied to determine the number of partitions and the number of users per partition. As a rule of thumb, we see the scalability doubled (meaning Domino can now support up to 4 processors per partition with scalable growth as processors are added) and approximately 1.5 to 2 X the number of users per partition. Example: With R4, if we have a 4-way running two partitions of 600 users each for a total of 1200 active users, then R5 with the same 4-way could support the same 1200 active users on a single partition (hence better administration). Therefore, as a guideline:

ŸR4 - one partition for every two processors

ŸR5 - one partition for every four processors

ŸR4 - one partition for every 600 - 800 active users

ŸR5 - one partition for every 1600 - 2000 active users

If workloads are unknown or heavy, then the lower limits should be planned for and then measurements made once in production.

When clustering is used, customers have reported approximately a 20-25% overhead. If calendaring and scheduling is used, an approximate 25% overhead should be applied.

Page 15

Lotus Domino Server R5 Implementation Guide

June 18, 2001



B. RS/6000 Domino Server Sizing Tool

The RS/6000 Domino Server Sizing Tool is a server-sizing, capacity-planning tool used to suggest server configurations based on benchmark information and on your customer requirements. You can evaluate different server offerings with a mix of workloads that map to your internal deployment, such as mail, discussion databases, groupware, and Web users. Because you can specify expected workload, it is the best tool for recommending which RS/6000 server to purchase based on your predicted load. The sizing tool currently is based on NotesBench and capacity data on Domino R4. When Domino R5 data is available, the Sizing tool will be updated and noted on the Business Partners site. Your IBM representative can access the sizing tool and assist in sizing recommendations.

Page 16

Lotus Domino Server R5 Implementation Guide

June 18, 2001



Sample Configurations

The verification test was run on the configuration mentioned previously. Below are sample configurations for light (small), medium, and high (large) workload /user communities. These are meant to be guideline configurations relative to memory, disk, and adapters. Specific configurations should be based on customer requirements. The configurations briefly described here can be found in Appendix A.

Small Configuration:

This RS/6000 configuration supports up to 2,700 active users of mail where the mail load is 5 times that of NotesBench. This configuration can be used for many solution examples, but if more than mail is used, the number of registered mail users would decrease dependent on the added application workload. There is an unofficial NotesBench test resulting in 13,500 users that can be used to demonstrate the performance factors of this model and support calculations to determine variations on the below configuration to support entry and growth requirements using the pSeries 640 expansion capabilities. (Note: Unofficial numbers may not be used officially or publicly to compare to NotesBench results published for other Notes server environments.) The configuration is an IBM pSeries model 640 with a 375 MHz 4-way 64-bit Power3-II processor, with 1164.8 GB disk and 8 GB memory.

Medium Configuration:

This configuration supports up to 5,606 active users of mail where the mail load factor is 5 times that of NotesBench. This configuration can be used for many solution examples, but if more than mail is used, the number of registered mail users would decrease dependent on the added application workload. There is an official NotesBench test resulting in 28,032 users that can be used to demonstrate the performance factors of this model and support calculations to determine variations on the below configuration to support entry and growth requirements using the M80 expansion capabilities. The configuration is an IBM RS/6000 model M80 with a 500 MHz 8-way 64-bit RS64 III processor, with 1747.2 GB disk and 16 GB memory.

Large Configuration:

This RS/6000 configuration supports up to 21,600 active users of mail where the mail load factor is 5 times that of NotesBench. This configuration can be used for many solution examples, but if more than mail is used, the number of registered mail users would decrease dependent on the added application workload. There is an unofficial NotesBench test resulting in 108,000 users that can be used to demonstrate the performance factors of this model and support calculations to determine variations on the below configuration to support entry and growth requirements using the pSeries 680 expansion capabilities. (Note: Unofficial numbers may not be used officially or publicly to compare to NotesBench results published for other Notes server environments.) The configuration is an IBM pSeries 680, 24-way 600 MHz 64-bit RS64 IV processor with 5241.6 GB disk and 96 GB memory.

Page 17

+ 37 hidden pages