Novell is now a part of Micro Focus

GroupWise 5.5 Performance and Capacity Planning

Articles and Tips: article

01 Aug 1999


This AppNote is adapted from a Compaq White Paper published in March 1999, document number ECG539/0399

Looking for ways to squeeze extra performance out of your GroupWise system? Get the latest tips and recommendations resulting from an extensive series of tests performed at Novell's SuperLab.

Overview of GroupWise 5.5

This document presents the results of a series of performance and capacity planning tests conducted jointly by Compaq and Novell, running GroupWise 5.5 with NetWare 5. This information will assist the reader in gaining a better understanding of the relationship between system resources and GroupWise 5.5 performance. It helps makes informed server configuration decisions when upgrading or purchasing a new system.

This document covers the following areas:

  • An overview of the GroupWise 5.5 product architecture

  • A description of the test methodology

  • A comprehensive analysis of the test results

  • Performance tuning recommendations

  • Detailed recommendations regarding user load variances and stress testing

  • Server-specific results based on the monitoring and utilization of system, processor, memory, and disk subsystems

This information provides a useful starting point for configuring the optimal platform to support GroupWise 5.5. In addition, an automated sizing tool is available to assist with determining the appropriate size and scope of a GroupWise environment. For more information, visit:

http://www.compaq.com/activeanswers

Overview of GroupWise 5.5

Novell's GroupWise 5.5 is one of the first messaging and collaboration solutions to blend the functionality of messaging, calendaring, and scheduling with document management. GroupWise can operate either as a file sharing-based messaging system or as a full client/server-based application with the server delivering both messages and documents. Other functions are also processed at the server level, such as gateways, indexing, routing, and administration.

A basic GroupWise system consists of a single domain and post office, and one or more users. Each GroupWise user has a mailbox within the post office. Users run the GroupWise client to access their mailbox and to send and receive mail from other users. The GroupWise agents deliver messages between users' mailboxes in a post office and also route messages between post offices, if they are part of a multiple post office system (see Figure 1).

Figure 1: Components of a basic GroupWise 5.5 system.

The domain within a basic GroupWise system serves two basic purposes:

  • Within a multiple post office system, the domain organizes post offices into logical groupings for addressing and routing purposes. Each user in the domain has an address that consists of the domain name, the user's post office name, and the user's GroupWise ID.

  • The domain functions as the main administration unit for the GroupWise system. When you add GroupWise information (such as other domains, post offices, and users) through NetWare Administrator, it is stored within Novell Directory Services (NDS) and the GroupWise domain database. From the database, GroupWise information is distributed to each post office database.

The GroupWise 5.5 architecture includes domains, post offices, and libraries. The domain and post office serve basically the same role that they have in the past. The optional library is a database used for storing information about documents within the GroupWise system. Information such as document properties, activity logs, and search indices are stored in the library.

Test Methodology

The tests, performed in Novell's SuperLab facility, were based on benchmarks developed by Novell engineers. They provide a means of comparing the results generated when GroupWise is running on different hardware and under various load conditions.

Test Environment

The following table indicates the configurations used for each Compaq server tested.


System

Processor

Memory

Network Adapter

Hard Disk

Compaq ProLiant 1600

Pentium II 400 / 450

256MB EDO

Compaq Netelligent100 TX

3x 2.1GB disks in a RAID 0 configuration with a SMART-2/P Controller

Compaq ProLiant 3000

Pentium II 300 / 333

256MB EDO

Compaq Netelligent100 TX

3x 2.1GB disks in a RAID 0 configuration with a SMART-2/P Controller

Compaq ProLiant 7000

Pentium II Xeon 400/ 1MB

256MB EDO

Compaq Netelligent100 TX

3x 2.1GB disks in a RAID 0 configuration with a Smart Array 3100ES

The test bed used for this GroupWise performance test consists of a system under test and a number of users generating a mail load. The software used for the system under test included NetWare 5 and GroupWise 5.5. The clients ran Windows 95 and GroupWise 5.5 Client for Windows 95.

Test Procedure

The tests were run using an automated test script. During each test, PC clients replied to mail messages initiated by a sending PC and then reported a response time to the controller. Response time is a measure of the time required by the Post Office Agent to respond to requests from GroupWise clients. Throughout the tests, Compaq and Novell engineers analyzed network server and environment performance and collected baseline statistics, using the NetWare MONITOR.NLM utility to check system resource levels.

Analysis of Test Results

This section presents a comprehensive analysis of the benchmark test results in the following areas:

  • System processor

  • System memory

  • Disk subsystem

  • Fault tolerance

  • Array controller

  • Volume block size

  • OS platform

  • Number of Post Offices per server

  • NetWare server settings

System Processor

NetWare 5, the latest release of Novell's network operating system, delivers superior performance and adds new reliability features. For example, Novell has re-designed the NetWare 5 operating system kernel to combine the outstanding performance of a single processor with the scalability of a multi-processor kernel (MPK). This new advanced NetWare kernel replaces SMP and provides an integrated single- or multi-processor OS to facilitate SMP-enabled network service.

Single vs. Multiple Processors. During the multi-processor tests, performance gains of 40-50 percent were consistently achieved. Figure 2 shows the improved scalability of GroupWise when using a server with dual processors running NetWare 5.

Figure 2: NetWare 5 MPK comparison with dual processors provided a 40-50 percent improvement in response time.

Pentium II vs. Xeon Processors. The performance of Pentium II 300, 333, 400, and 450 processors was compared to the performance of the Pentium II Xeon/400 processor. Test results revealed that processor clock speed has a significant impact on performance. In fact, system processor performance has a greater impact on GroupWise server performance—and therefore on client response time—than do memory, disk, or network interface card. The greater the server processing power, the lower the response time. For example, the response time can be improved by 40 percent if the processor is upgraded from a Pentium II 300 to a Pentium II 400 processor (see Figure 3).

Figure 3: In CPU performance across a range of processors, tests showed the best performance using a Pentium II Xeon/400.

Processor Cache. Level 2 cache is another important processor performance factor. Level 2 cache memory is the high-speed static RAM that resides between the CPU and the main system memory. Level 2 cache stores snapshots of the most recently used regions of system memory in fast static RAM memory so it is available immediately to the processor. Since Level 2 cache memory returns information to the processor quicker than system memory, the processor spends less time waiting for the main system memory to return data and more time performing actual processing work.

Current Pentium II processors only have 512KB of Level 2 cache memory. The Pentium II Xeon processor can accommodate fast and large (up to 2MB) caches to keep data moving at very high speeds through the processor core. As shown in Figure 3, the response time achieved by the Pentium II Xeon processor is 30 percent faster than that of a non-Xeon-based Pentium II processor, even though both processors have an equivalent clock speed of 400 MHz.

System Memory

The amount of total server memory has a significant impact on operating system performance. The memory requirements of GroupWise 5.5, in particular, vary according to several factors. For instance, too much memory can degrade performance since the system and processor are forced to manage a large pool of memory.

During memory testing, the number of active users was held at 240 on a single Compaq ProLiant 3000 server with a Pentium II 333/512KB processor. The memory configuration varied from 128MB through 512MB (see Figure 4). A ProLiant 3000 configured with a Smart-2/P disk array controller and a RAID 0 array with 3 striped drives was used to handle the NetWare volume.

Figure 4: Adding 128MB of memory for a total of 256MB can improve response time by 15 percent.

Disk Subsystem

Since GroupWise is an I/O-intensive application, the type of disk subsystem used contributes significantly to overall system performance. It is therefore important to determine the impact of various disk subsystem options and to alleviate potential bottlenecks. These options include:

  • Type of fault tolerance: RAID 0, RAID 1, RAID 3, RAID 4, RAID 5

  • Array Controller Accelerator Read/Write Ratio

  • Volume block size

Fault Tolerance. Redundant Arrays of Independent Disks (RAID) is a term used for an array technology that increases overall system reliability and performance. This technology offers several methods of using multiple disks to improve system performance while enhancing data reliability and preventing data loss. Several types of RAID configurations, called levels, have been developed. The fault tolerance method selected will have an impact on the amount of disk storage available and the performance of the drive array. The following levels of fault tolerance support are available.

  • RAID 0 (Disk Striping). This RAID level is not truly fault-tolerant because it does not provide data redundancy and therefore does not provide fault protection against data loss. If one of the logical drives fails, data on that drive will be lost. None of logical drive capacity is used for redundant data. RAID 0 is known as "stripe sets" because data is simply striped across all of the drives in the array.

    This configuration provides high performance at low cost, but at the risk of possible data loss.

  • RAID 1 (Drive Mirroring). This is the fault tolerance method typically used for the best performance. RAID 1 is the only option for fault tolerance available if no more than two drives are selected. This configuration of mirrored sets of data uses 50 percent of drive storage capacity to provide greater data reliability by storing on a separate disk drive duplicates of all user data. Therefore, half of the drives in the array are duplicated or "mirrored" by the other half.

    This RAID level provides performance equal to, or better than, RAID 0, but drive costs double because this level requires twice as many disk drives to store the same amount of data. Therefore, this option may not be viewed as cost-effective as other RAID levels, depending on the user environment.

  • RAID 3. This level adds redundant information in the form of parity to a parallel access striped array, permitting regeneration and rebuilding in the event of a disk failure. One strip of parity protects corresponding strips of data on the remaining disks.

    RAID Level 3 provides high data transfer rate and high availability at an inherently lower cost than mirroring. Its transaction performance is poor, however, because all RAID Level 3 array member disks operate in lockstep.

  • RAID 4 (Data Guarding). This level is referred to as data guarding because it uses parity data to guard against the loss of data in a way similar to RAID 5, which is called distributed data guarding. The difference is that RAID 4 writes all of the parity data to a dedicated single drive in the array. If a drive fails, the parity data and the remaining functioning drives with data use the parity information to reconstruct data from the failed drive. Problems may arise if the drive or drives that fail contain the parity information; in which case, the parity drive data cannot be reconstructed.

    The usable disk space for a RAID 4 configuration is the same as for RAID 5, except that the space required for parity is housed on a single drive. For example, if you have a three-drive system, 33 percent of the total drive space (the equivalent of one drive) will be used for fault tolerance. In this case, two drives store data and one drive stores the parity data. A maximum of 14 drives can be supported in this way. Of these 14 drives, 7 percent of the total space available, or one drive, would be used for parity data. Writing all the parity data to a single drive also introduces performance degradation, since parity data is not being striped across all drives. Disk configurations using RAID 4 for fault tolerance have historically proven to yield performance results at a level below RAID 5 configurations.

  • RAID 5 (Distributed Data Guarding). This level is commonly called "Distributed Data Guarding" or "Stripe Sets with Parity". This level of RAID actually breaks data up into blocks, calculates parity, and then writes the data blocks in "stripes" to the disk drives, saving one stripe on each drive for the parity data.

    This method is cost-effective, with the added benefit of providing high performance because the parity information is distributed across all the drives. The total amount of disk space used for redundancy is equivalent to the capacity of a single drive; therefore, the overall cost for this method of fault tolerance is lower than that achieved using RAID 1.

The GroupWise 5.5 tests were used to generate comparisons of fault tolerance levels, including RAID 0, RAID 1, and RAID 5. The tests were run on a Compaq ProLiant 3000, 1xPentium II 333/512K, with 256MB of RAM. They included 240 active users. The RAID 0 and RAID 5 tests were performed using three 4.3GB drives in an array. The RAID 1 test was run using six 4.3GB drives, with three drives serving as a mirror of the other three. Results are shown in Figure 5.

Figure 5: While RAID 0 provides the best performance, RAID 5 is the best option for guarding against critical data loss.

The test results show that RAID 0 had the best performance, outperforming RAID 1 by 10 percent and performing about 20 percent better than RAID 5. Even though RAID 0 uses disk space most efficiently, it does not provide fault protection against data loss. Therefore, for a system with critical data, RAID 5 is frequently the choice of customers since it provides better usage of disk space.

Array Controller Accelerator Read/Write Ratio. The Compaq Array Controller Configuration Utility offers five options for Read/Write ratios: 0/100, 25/75, 50/50, 75/25, and 100/0. During the Read/Write Ratio test, the number of active users was held to 245 on a Compaq ProLiant 3000 Pentium II 333/512K. The Read/Write Ratio was configured at 25/75, 50/50, and 75/25. The PL3000 was configured using a Smart-2/P disk array controller. A RAID 0 array of 3 striped drives was used to handle the NetWare volume. Test results are shown in Figure 6.

Figure 6: A 75/25 Read/Write ratio provided the best performance.

The test results show the Read/Write Ratio at 75/25 achieved best performance, outperforming the other two configurations by 20-30 percent.

Volume Block Size. One important feature of NetWare is the capacity to support large volume block sizes. A block is a unit of storage for data held within a NetWare volume. Using a large volume block size increases the performance of almost every associated subsystem, such as disk channel, file cache, directory cache, directory entry table, and file allocation table (see Figure 7).

Figure 7: A 64KB volume block provided the best results.

The results show noticeable improvement in response time when the volume block size is set to 64KB. Compaq and Novell engineers recommend that you always select a volume block size of 64KB because with smaller block sizes, more system memory is consumed to manage the blocks. With the sub-allocation feature provided in NetWare, a block size of 64KB will give you the best performance for reading and writing files without losing disk space.

Operating System Platform

Running GroupWise in a NetWare 5 environment offers great performance improvement. Tests were conducted using GroupWise 5.2 on NetWare 4.11 and GroupWise 5.5 on NetWare 5. The results indicate that NetWare 5 provides GroupWise with a performance boost over NetWare 4, as measured by response time. The tests further illustrate that GroupWise 5.5 with NetWare 5 outperformed GroupWise 5.2 with NetWare 4.11 by about 30-80 percent and reduced significantly the response time of GroupWise clients (see Figure 8).

Figure 8: GroupWise 5.5 on NetWare 5 outperformed GroupWise 5.2 on NetWare 4.11.

Running GroupWise 5.5 on Windows NT. GroupWise 5.5 will run on both NetWare and Windows NT servers. To compare the performance of GroupWise 5.5 running on NetWare and Windows NT, the following GroupWise 5.5 configurations were tested:

  • GroupWise Post Offices on a NetWare Server running the NetWare-based NLM with the Message Transport Agent (MTA) loaded on the same server.

  • GroupWise Post Offices on a Microsoft Windows 4.0 NT application server with the MTA running on the same server.

    To better compare NetWare and Windows NT performance, the FAT file system was used during this test. GroupWise does run on NT with the NT File System, but that configuration was not tested at this time.

The test results indicate that running GroupWise 5.5 on NetWare performs much better than running GroupWise 5.5 on Windows NT (see Figure 9).

Figure 9: GroupWise 5.5 on Windows NT did not perform as well as GroupWise 5.5 on NetWare.

Number of Post Offices Per Server

GroupWise permits a single server to host multiple post offices. However, this configuration may lead to performance degradation. With multiple post offices running on the same server, each post office agent will initialize threads for anticipated workloads. In periods of idle time, these threads have to be maintained and controlled by the owning process, which consumes system resources.

For example, suppose there are three post office agents on a given server. If two post office agents (POAs) are relatively idle and the third POA is very busy, the third POA cannot use the other two POA threads since those threads consume resources while simply being maintained. If one of the idle POAs should be triggered to kick off Quick Find Indexing, there is no way for the busy POA to prioritize the client/server threads it requires. It is therefore recommended that the optimal configuration consist of one post office per server (see Figure 10).

Figure 10: Using multiple post offices on a single server will lead to performance degradation.

Server Settings

Several NetWare server settings have been found to have an important impact on Post Office Agent performance. System administrators need to be familiar with these settings and adjust them based on performance needs and stability requirements. During the tests, several server settings were changed to gauge the impact on performance. These are explained below.

Read-Ahead Cache. The read-ahead cache feature in NetWare provides the requesting workstation with a faster response when reading files from a server. The operating system anticipates the read requests from the workstation and caches the next volume or disk block of a file.

Compaq and Novell engineers recommend that users enable read-ahead cache to enhance read performance. Figure 11 shows the performance gain achieved when enabling read-ahead.

Figure 11: Response time improves when read-ahead is enabled.

Maximum Service Processes. Changing the maximum number of service processes will impact performance since this setting also consumes system resources. When the maximum service processes was changed from 500 to 1000, a 10 percent improvement in performance was noted (see Figure 12).

Figure 12: Increasing the Maximum Service Processes setting will improve response time.

Since this setting consumes system resources, system administrators should monitor this setting using MONITOR.NLM. If the current processes begin to approach the maximum, it is a good idea to increase the maximum service processes.

New Service Process Wait Time. When a service process is requested, a new one can be created quickly if this setting is low. With the default setting of 2.2 seconds, the theory is that if the system waits long enough, a process will become free. If there is sufficient memory, there is no harm in creating a process to react instantaneously to the initial request.

During the tests, the default setting was changed to 0.3 seconds. This setting improved GroupWise performance by 10 percent (see Figure 13).

Figure 13: Lowering New Service Process Wait Time from 2.2 to 0.3 seconds improved response time by ten percent.

New Packet Receive Buffer Wait Time. If the server has sufficient memory, lowering this setting can significantly increase productivity (see Figure 14). As with service processes, the server will immediately spawn a new buffer without waiting to see if one becomes available first.

Figure 14: A New Packet Receive Buffer Wait Time setting of 0.1 seconds may consume more memory, but will enhance response time.

Test results indicated that performance degraded when the New Packet Receive Buffer Wait Time setting was adjusted to 1 second. Although changing the setting to a lower number consumes memory, it will enhance system performance, assuming that sufficient memory is used.

Performance Tuning

The following performance tuning information is based on a mixture of in-house testing, third-party lab performance studies, and technical support experience. To achieve optimal levels of performance tuning and optimization, it is important to monitor server performance and analyze the system environment. Baseline statistics should first be collected before making any changes to the server.

Prior to outlining these recommendations, it is important to list various assumptions. These assumptions should serve as guidelines for planning the growth of an existing GroupWise system or for installing a new GroupWise system.

The assumptions used for these guidelines are as follows:

  • GroupWise version 5.5 or higher

  • Any patch level of GroupWise 5.5

  • Pentium Pro 200 or better server

  • Dedicated server (one that handles only e-mail; users do not log in for other applications, NDS authentication, or file and print services)

  • One domain per server

  • One MTA per domain

  • One MTA per server

  • MTA running on the same server as the domain

  • MTA running with IP links to other domains and Post Offices

  • One Post Office per server

  • One POA per Post Office

  • One POA per server

  • POA running on the same server as the Post Office

  • TCP/IP connection used for client access

The following discussion contains recommendations based on these prior assumptions.

GroupWise POA Optimization

You can adjust how the POA functions in order to optimize its performance. Before attempting optimization, however, you should run the POA long enough to observe its efficiency and what impact it may have on other network applications running on the same server or workstation. Also, keep in mind that optimizing your network hardware and operating system can make a difference in POA performance.

The POA object has many settings that can be configured. Several of these can increase or decrease the performance of the POA. These settings are available so that system administrators can change them based on whatever need exists for achieving optimal performance and stability.

TCP Handler Threads for Client/Server Processing = (1 for 20-30 users)

Threads are processes that run in the operating system. TCP Handler threads are TCP/IP threads that handle the client/server requests from GroupWise client users. If the POA is not keeping up with these requests, you can increase the maximum number of TCP handler threads so the POA can create additional threads. The optimum number of threads for a POA is affected by many factors, including available system resources.

The default is 8 TCP handler threads; valid values range from 1 to 50. It is safe to assume roughly 1 TCP handler thread per 20-30 client/server users. An alternative is to increase the number of TCP handler threads in increments of three to five threads until acceptable throughput is reached.

It has been found that the appropriate setting depends on how active users are. When users are less active (averaging only 5 to 10 items per day, both sent and received), 30 users per thread is sufficient. However, if users are more active (more than 30 items sent and received each day, in addition to Finds and Busy searches), 20 users per thread is recommended.

It is important to adjust this number for every situation because each thread allocated takes memory and resources. On the other hand, if not enough threads are allocated, there will be pending requests and a resultant slower response time for all users.

Enable Automatic Database Recovery = On

This setting enables the POA to detect database problems and fix them in most cases. In the long run, this will improve performance because it prevents problems from getting serious before they are detected and corrected.

Novell recommends that the automatic database recovery remain enabled (the default setting); the trade-off in stability is worth the possible loss in performance.

QuickFinder Indexing = On

The QuickFinder is used to speed up the processing of query results for both a find and document search. QuickFinder takes up a lot of system resources on the server and will often cause utilization levels to peak until indexing is complete. However, it is recommend that you leave this setting turned on (the default).

With GroupWise 5.5, a new setting was added to permit indexing to start at a specific time, on a specific offset from midnight. This gives the administrator more control to run the QuickFinder at low system usage times.

Max App Connection = (4 per user)

Application connections are virtual connections. They are the workhorses for the IP traffic between client and POA. As new communication between client and POA is required, a new application connection will be spawned. After 5 seconds of no use, application connections will time out and terminate.

The default setting is 2048. The recommended setting is 4 per users, since an average user will use approximately 4 connections per session at any given time. Each connection takes up approximately 8KB of memory.

When application connections hit the maximum, the oldest connection is removed to take care of new requests. If the old connection is still in use, the client will request the new one, thereby launching into a "vicious circle" of connection requests. If users complain about connection speed, this setting may be too low.

Max Physical Connections = (1 per user)

A physical connection must be created in order to generate application connections. A user can have multiple physical connections.

In general, one physical connection per user is sufficient because not all users are going to be active at the same time. (The default setting is 512.) If the GroupWise system reaches the maximum number of physical connections possible, users will receive an error indicating that they cannot connect to the GroupWise system. Increasing the maximum physical connections does not pre-allocate memory.

CPU Utilization for NLM POA

To ensure that the NetWare-based POA does not dominate the server CPU, the NLM has a CPU utilization threshold. The default CPU utilization threshold is 85 percent. You can change this threshold using the CPU Utilization option. If CPU utilization exceeds the threshold by 5 percent, any idle POA threads remain idle for the number of milliseconds set by the Delay Time option. This cycle continues until CPU utilization drops below the CPU utilization threshold.

To determine the optimum utilization setting for your network, consider the amount of available memory, the demands of other network applications, and the type of throughput the POA should provide. As the utilization threshold is raised, POA efficiency increases; however, other network applications will have fewer network resources available. As the utilization threshold is decreased, POA efficiency is reduced, but the NLM will cooperate better with other network applications.

The following table provides general guidelines for setting the CPU Utilization and Delay Time settings, based on the amount of memory available on the server where the POA runs. The values in this table are only guidelines. The best way to determine these settings for your network is to experiment.


Memory

Setting

4MB

CPU Utilization: 25 Delay Time: 500

8MB

CPU Utilization: 50 Delay Time: 300

16+MB

CPU Utilization: 85 Delay Time: 100

Server Optimization for GroupWise

The following server settings have been found to have an impact on GroupWise system performance.

Directory Cache Buffer Non-referenced Delay = 30

This setting will decrease processor overhead and I/O traffic. It determines how often the Directory Cache buffer is refreshed. Every refresh requires a new disk read and write to memory. By increasing the value to 30 seconds (from the default of 5.5 seconds), you decrease how often the refresh takes place.

Minimum Directory Cache Buffers = (2-3 per connection)

By increasing the value (the default is 20), the buffer is already established and no additional resources are required to allocate more memory on the fly. This can eliminate processor and I/O bottlenecks.

Maximum Directory Cache Buffers = 4000

This setting protects the system from using too much memory for Directory Cache Buffers. However, the default of 500 does not typically give the system enough room to grow. A setting of 4000 gives the system some leeway, but may require additional memory.

Read-Ahead Enabled

The read-ahead feature significantly increases performance on NetWare servers. The read-ahead feature predicts what files are required next and loads them into memory for access. The default setting is On (enabled).

Read-Ahead LRU Sitting Time Threshold = 60

This feature is for the read-ahead mechanism. The read-ahead LRU Sitting Time Threshold says that if the LRU (Least Recently Used) is below the specified time, do not use the read-ahead feature. LRU is an algorithm that is used for memory block/page replacement. An LRU list identifies the least recently-used cache blocks (blocks that have been in cache the longest time without being accessed) and flags those for use first. It makes for a more efficient caching implementation. The reason for the above setting is that if there is not enough memory to access data from available cache, read-ahead will take up memory and processor time without increasing performance. If read-ahead is not helpful, it makes sense not to use these resources.

This setting can be configured up to 1 hour. The default is 10 seconds. In general terms, if the LRU is 20 minutes or better, the system will likely have sufficient memory available. This setting could be effective anywhere from 60 seconds to possibly 5 minutes. (Be aware that increasing this setting disables read-ahead, which usually is not recommended. If this option is used a lot, it is probably time to add more memory.)

Minimum Service Processes = 100

Service Processes are dynamic. By pre-allocating them, less overhead is required to allocate them on the fly. As long as there is sufficient memory, this number can be increased. The default is 10.

A good rule of thumb is to monitor the server during peak times, and then set the Minimum Service Processes to whatever the current service processes are during peak times.

Maximum Service Processes = 1000

Increasing this setting from the default of 40 takes up resources. Monitor this setting using MONITOR.NLM. If the current processes begin to approach the maximum, increase the maximum service processes.

New Service Process Wait Time = 0.3

Changing this setting can drastically increase performance. When a Service Process is required, a new one can be created quickly. With the default setting of 2.2 seconds, the theory is that if the system waits long enough, a process will become free. If there is sufficient memory, decrease the wait time to 0.3 seconds. There is no harm in creating a process instantaneous to the initial request.

Minimum Packet Receive Buffers = (2 -3 per user)

Any request that is processed uses a Packet Receive Buffer. This includes all NCP, SAP, and RIP requests, TCP packets, and so on. Under normal conditions, NetWare dynamically allocates the packet receive buffers based on current needs. However, the operating system allows you to set the minimum and maximum number of buffers If the server is bombarded with requests and there are not enough packet receive buffers, the system will get bottlenecked and will start dropping requests. The result is loss of connection to users, loss of server-to-server connections, slowness, and so on. A good suggested minimum is 2-3 buffers per users; the default is 50.

It is important to monitor the current packet receive buffers during peak times to see if the value is close to the maximum. If this is the case, you should increase the maximum packet receive buffers to accommodate the increased workload. Make sure that the minimum is set to that current setting so that there are enough packet receive buffers running at all time. However, keep in mind that increasing the minimum number of packet receive buffers takes system memory from the NetWare memory pool. Be certain that increasing this value does not leave the server with too little memory.

New Packet Receive Buffer Wait Time = 0.1

If the server has sufficient memory, decreasing this setting from the default of 1 second can significantly increase productivity. As with service processes, the server will immediately spawn a new buffer without waiting to see if one becomes available first.

Capacity Planning

Capacity planning is a method of determining the balance between a GroupWise 5.5 workload and its configuration at minimum cost, while meeting necessary user response time objectives. The goal of capacity planning is to find the best server and equipment mix to meet network workload demands and performance requirements in a cost-effective manner. Capacity planning allows you to balance the demand for present and anticipated workload and the supply of present and future computer resources. A basic objective is achieving consistent and acceptable user response times.

Capacity planning may be one of many responsibilities of the system administrator or integrator. Capacity planning is closely tied to performance management. GroupWise performance depends on the number of users on the system, the operating environment of the server and workstations, and the bandwidth and speed that are available to the physical network. The type of server, network adapter, and cabling system plays an important role in how the network operates under heavy traffic conditions.

In capacity planning, the planner must balance complex, vague, and sometimes confusing data about workload, user needs, and computer resources, then devise a coherent plan and make these needs known to others. Although capacity planning requires the use of statistical data and mathematical techniques, it is not an exact science. It is helpful to have practical experience and expert-level knowledge of the computer industry.

Planning the appropriate hardware server platform to meet the needs of users can be one of the most important strategic planning tasks performed by a GroupWise administrator. Whether it is over-estimating or under-estimating your computer resource needs, poor planning affects the corporate bottom line. Over-estimating results in a network server that costs more and has more capacity than users will ever need. On the other hand, most planners err on the side of caution by not planning far enough ahead into the future and end up with insufficient computer capacity.

The amount of time, effort, and cost spent properly planning a GroupWise implementation will be worth the investment when the system adequately meets user response-time expectations and optimally utilizes system resources.

Basic GroupWise System Requirements

The following table summarizes the requirements for a single domain, which includes one domain with one post office.


Item

Requirement

NetWare 4.x or 5.0

GroupWise is administered through NetWare Administrator and NDS

NetWare Administrator and GroupWise Administrator

NWADMN32.EXE (installed by GroupWise if necessary)Windows 95 workstation with NetWare Client 32 for Windows 95 or Windows NT 4.0 workstation with NetWare Client 32 for Windows NT80486 processor16 MB RAM

Domain Disk Space

10 MB (Minimum)

Post Office Disk Space

2 MB per user (minimum)10 MB per user (recommended)

Software Distribution Directory Disk Space

300MB maximum on network directory. This will be less if you choose not to install some GroupWise clients or agents.

NLM Agents

NetWare 3.12, 4.x, or 5.0 serverMTA: 6 MB free disk space, 6.5 MB free RAMPOA: 6 MB free disk space, 5 MB free RAM (1.5 MB if running on same server as MTA or ADA)

NT Agents

Windows NT 3.51 server or workstationMTA: 4.5 MB free disk space, 6 MB free RAMPOA: 4.5 MB free disk space, 5 MB free RAM (1.5 MB if running on same machine as MTA)

Windows 95 GroupWise Client

Windows 95 workstation or Windows NT 4.0 workstation80486/33 processor (minimum)48 MB free disk space to run from local drive5 MB free disk space to run from network drive16 MB RAM (Windows 95)24 MB RAM (Windows NT)

Windows 3.1 GroupWise Client

Windows 3.1 workstation or Windows 95/NT workstation80386/33 processor20 MB free disk space to run from local drive2 MB free disk space to run from network drive8 MB RAM

System Processor

The tests clearly show that the system processor is the most important subsystem affecting overall system performance of GroupWise 5.5. The faster the system processor, the better the performance gain for the overall system. Compaq and Novell engineers recommend the fastest processor that can be purchased within the budgetary limitations of your project.

The following quick guide illustrates the range of users each server can support:


 

Number of Users

Compaq Server Platform

300

500

600

800

1000

1200

1400

ProLiant 7000 Xeon

X

X

X

X

X

X

X

ProLiant 6500 Xeon

X

X

X

X

X

X

 

ProLiant 6000 Xeon

X

X

X

X

X

X

 

ProLiant 5500 Xeon

X

X

X

X

X

X

 

ProLiant 3000 Pentium II

X

X

X

X

X

 

 

ProLiant 1850R Pentium II

X

X

X

 

 

 

 

ProLiant 1600 Pentium II

X

X

X

X

 

 

 

ProLiant 800 Pentium II

X

X

X

 

 

 

 

Note: These recommendations are based on real-world user numbers and not on simulated benchmark numbers. They are based on system models available in November 1998. The maximum numbers of users assumes a use of 4 processors in the PL6500 and PL7000 servers.

Memory Configuration

The memory requirements are upper limits for a high usage messaging system. The memory required on a server for GroupWise 5.5 depends on many factors. The recommendation presented below should serve as general guidelines for calculating memory requirements. A GroupWise system will run with less than the maximum amount of memory, but it will perform much better with adequate memory. Memory amounts stated are for GroupWise 5.5 and not total system memory.

Factors to consider that may cause variances in calculations and performance are as follows:

  • Number of post offices and domains

  • Number of TCP Handlers and MF worker threads

  • Number of client/server connections being supported

  • Message traffic between post offices and domain

  • Separate processors for POA, MTA, and ADA

  • IP or direct connections between MTAs

  • High volumes of admin-related traffic

  • High volumes of large messages (large attachments, remote updates, and others)

Compaq and Novell engineers have provided the following memory recommendation guidelines. The system administrator can use the table below as a guideline for initially determining the GroupWise memory requirements. Once in production, the administrator can use NetWare monitoring tools such as MONITOR.NLM to monitor memory utilization during operations to determine whether or not a memory upgrade is necessary.

The following table lists the recommended memory configuration by number of users.


Number of Users

Recommended Memory Configuration (MB)

150 or less

218

300

308

500

428

600

488

800

608

1000

728

Disk Subsystem Configuration

Disk striping can be beneficial in terms of a gain in I/O performance. The recommendation is to use numerous smaller drives in an array rather than a few larger drives in order to achieve the best overall system performance providing comparable capacity. Hardware striping can be achieved with Compaq's Smart Array Controller Family or StorageWorks RAID Storage Systems. Both have built-in data protection features. The Smart Array Controllers have an underlying intelligent I/O architecture that has been streamlined for high performance. The advanced architecture consists of optimized hardware and firmware components working together efficiently, with functions and embedded intelligence distributed across appropriate points in the design.

For instance, the Smart Array 3100ES Controller is a new design based on Smart-2 array architecture. It offers three UltraWide SCSI-3 channels that provide over 218 GB of high-availability fault-tolerant storage within the ProLiant 6000 and 7000 models. With new and larger 56-MB ECC-protected and battery-backed removable read/write cache, I/O performance will be maximized without sacrificing data integrity.

For larger highly-available storage subsystem requirements, Compaq offers the Fibre Channel RAID Array 8000 (RA8000) and Enterprise Storage Array 1200 (ESA12000). These RAID Array subsystems provide storage capabilities up to 1.3TB. The 512MB of cache memory per controller and up to 1GB of cache per redundant controller pair ensure high performance.

Fault tolerance is strongly recommended by Compaq and Novell engineers. RAID 5 is the preferred level of fault tolerance for systems that carry mission critical data. RAID 5 uses distributed data guarding, striping data and parity data across all drives in the array. The more drives in the array, the lower the portion of each drive reserved for fault tolerance support.

Disk access is often a major bottleneck to good GroupWise system performance. When possible, use the fastest available UltraWide SCSI drives connected to controllers that support UltraWide transfer rates.

Number of GroupWise Domains

There is no limit to the number of domains that can be contained in a GroupWise system. However, to ensure proper synchronization, Novell recommends that this number not get too high. The more domains in a system, the more databases that require synchronization. The primary domain should not have any post offices and should have a direct TCP/IP to all secondary domains, where possible. This ensures that administration traffic is isolated from message delivery routes. It also ensures that administration changes are replicated as quickly as possible throughout the system.

However, the primary domain should not be used as a routing domain, since administration traffic should remain separate from message delivery traffic. If the system contains multiple high-traffic gateways, all gateways should be put on a separate secondary domain gateway. Additional domains for Internet traffic (Web Access) can be placed at WAN/LAN hub locations to reduce the time and cost of message delivery and network bandwidth. If there are other high-traffic gateways, they can be placed on separate domains on separate boxes in order to boost processing power.

Number of Post Offices Per Server

GroupWise permits the use of a single server to host multiple post offices. However, this configuration may lead to performance degradation. With multiple post offices running on the same server, each post office agent will initialize threads for anticipated workloads. In periods of idle time, these threads have to be maintained and controlled by the owning process, which consumes system resources. Compaq and Novell engineers recommend only one post office per server.

Database Maintenance

When deploying a GroupWise solution, it is important to put in place a data clean-up policy to control the size of the GroupWise server database or the size of user mailboxes. The larger the database, the longer the maintenance routines required. In addition, as the number of messages a POA must query for Finds and/or indexing increases, the POA slows down. The larger the user's mailbox gets, the longer it takes for the client to display items. Users are certain to be dissatisfied with poor response time results.

Compaq Sizing Tool for GroupWise

The Compaq ProLiant Sizer for Novell GroupWise is an automated tool that can assist you in determining the size and scope of your GroupWise environment. It provides a quick and consistent methodology to determine a "best-fit" server for GroupWise. The sizing information and algorithms have been developed using testing and performance data on Compaq ProLiant Servers running the GroupWise server.

The interview dialog session asks you questions about the kind of work you perform and the kind of information you need to store on your server. The interview dialog allows you to limit the processor configurations and hard drives considered by the sizing process. Using the information collected by the interview dialog session, the sizer configures a solution set to meet all of your requirements. The performance drives the sizing process. The performance of your application on the configured solution set is estimated based on performance testing data collected by Compaq.

The completed solution report includes server model, processor and memory upgrades, array controllers, hard drives, and storage systems. If a single server cannot satisfy your requirements, the Compaq ProLiant Sizer automatically provides a multiple-server solution. The report includes detailed part lists and cabling, rack diagrams, as well as detailed power and thermal requirements.

Channel representatives or field engineers can easily customize the report provided by the sizing tool with their own information, including name, telephone number, e-mail address, and so on. You can also e-mail the solution report with the press of a button. The program will automatically attach all associated files.

The Compaq ProLiant Sizer for Novell GroupWise reduces planning time and cost, and eliminates the trial and error usually involved in planning new configurations. This sizing utility is available for download at:

http://www.compaq.com/activeanswers

Conclusion

Planning for sufficient computer capacity for a GroupWise 5.5 solution is an ongoing process that makes it possible to avoid over-spending and planning for insufficient capacity. It is well worthwhile spending time and effort to plan a GroupWise server implementation correctly. The information presented in this AppNote should assist users and administrators with determining the best-fit solution for implementing a GroupWise 5.5 system.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates