Best Practices

Post office agent performance is important to your users. If the agent does not have the resources it needs to quickly process client/server requests, your users will notice. The client will be sluggish and nonresponsive, and users might think their workstations have locked up. It is therefore critical that the system be built and configured so that the POA is always performing well for your users.

Carefully Considering Settings That Impact POA Performance

There are several settings that can affect the POA's performance. Many of the settings will not affect the POA's performance, if just one or two of them are poorly configured. However, the cumulative effect of several settings incorrectly configured can degrade performance. Here are several settings or conditions to watch for, and some brief detail about each of them:

POASettings

• Generally, you want one TCP handler thread allocated for every 25 users.

• Generally, you want one message handler thread allocated for every 50 users.

• For our customers, we set the CPU Utilization on the Agents Settings page of the POA on a dedicated GroupWise server to 95.

• If your post office is composed of caching users, set the Max Thread Usage for Priming and Moves on the Agent Settings page to 50%.

• Turn off SNMP on the POA if you are not using an SNMP monitoring solution.

• Make sure that QuickFinder Indexing happens after business hours.

• Always enable Perform User Upkeep to happen sometime after midnight. If you do it before midnight, the task items will not advance, nor will the trash items be emptied, until users log in the next day. Make sure that your QuickFinder Indexing and your Perform User Upkeep do not run at the same time. You probably should space them out by about four hours.

• Run scheduled events at a different time than when the QuickFinder indexing and the Perform User Upkeep run.

Post OfficeClient Options

• Determine whether you are going to allow junk mail handling. You do not want to make the junk mail handling feature your only anti-spam solution. This is inefficient for a couple of reasons. First, the spam makes it all the way through your network, just to be rejected prior to the user getting it. Second, the POA will have to chug through all the users on the junk mail list to determine whether the message should be rejected.

• Turn off wildcard addressing, unless you really intend for users to use this setting.

• Consider setting user limits on mailbox size, and maximum sent message size.

• In the Send options, consider which kind of status tracking you need. Some customers have set their status tracking to All Information. This level of status tracking can be a drag on a GroupWise system. For optimal performance, set the Send options status tracking to Delivered and Opened.

Limiting the Size of the Post Office

The first mistake made by many administrators is overloading the post office. Unfortunately, it is very difficult to determine exactly how many users can belong to a single post office. Performance depends more on what the users are doing than on how many of them there are.

In practice, GroupWise administrators have seen that having more than about 700 users in client/server (online mode on the client) on a GroupWise post office often results in poor performance.

Creating post offices with thousands of users that are in both online and caching mode is not generally feasible. If you intend to grow to a larger post office, all the users on the post office should be in caching mode.

Limiting the Size of the Message Store

Post office agent performance degrades, and memory requirements increase, as the size of the message store grows. Performance problems are intensified if users keep too much mail in their master mailboxes. For a 700-user post office, we recommend purging mail older than 180 days. This should ensure good performance. If you do not have an email retention and expiration policy in place, you might consider using a third-party archiving solution, such as GWArchive, available at www.gwtools.com; Nexic Discovery, available at www.nexic.com; or other such solutions available from Novell's GroupWise partners.

Using One Post Office Per Server

If you have a choice between putting two 350-user post offices on a single server, and putting one 700-user post office on that same server, we recommend the 700-user option. The POA will load-balance in favor of client/server threads, but if there are two POAs running on one CPU, they cannot "talk" to each other to determine the best allocation of the limited resources. Placing more than one post office (and, therefore, more than one POA) on a single file server is not recommended. That said, putting a few 100-user post offices on the same server will generally not cause problems, and is in fact a common practice. It's the larger post offices that have problems with two on a server.

As with the size of the post office, the number of post offices per server is an area where you might be able to ignore my advice and get away with itespecially on heavy-hitting hardware. Just be sure to consider our recommendations.

Dedicating the Server to GroupWise

If you have more than 200 users in the post office, don't use this server for other applications. User home directories, eDirectory authentication, APPS volumes, and web servers should be on separate hardware. Your users will grow to depend on GroupWise more than almost any other application they run. They will demand good performance out of it, so GroupWise deserves to be treated as a mission-critical application. If another application can steal CPU slices out from under your POA, your users might eventually rise in revolt.

Monitoring Your POA Through a Web Browser

The GroupWise POA can be monitored through a Web browser. In fact, you can even suspend and restart some processes on the GroupWise POA. You can find lots of information about how your POA is functioning that you cannot find out in any other manner. For example, with the web-browser monitoring interface of the POA, you can determine exactly which users are logged into the post office. You'll still find it useful to use the POA's console interface on your NetWare or Windows server, but as for monitoring the POA, nothing beats the Web-browser interface of the POA.

Simple Configuration

The GroupWise POA needs three settings tweaked in order to support HTTP monitoring of the POA:

• An HTTP port specified

• An HTTP monitoring username specified

• An HTTP monitoring password for the username specified

You can configure all of these settings in ConsoleOne.

HTTP Port

To specify your HTTP port, go to the Network Address property pages of your POA object in ConsoleOne. Fill in the HTTP Port field. Fill in the HTTP port with a value that you know is unique. Don't use the same port as the client/server port or message transfer port.

HTTP Username/Password

To specify the HTTP username and password settings, go to the Agent Settings property page of the GroupWise POA object.

At the bottom of the GroupWise Agent Settings property page, fill in the HTTP username field and the HTTP password field.

Note

The HTTP username and password are not required to enable HTTP monitoring of the POA. It is highly recommended to enable the HTTP username and password feature, however, in order to secure access to the HTTP port of the POA.

Monitoring the POA with a Web Browser

Monitoring of the POA from a web browser is a particularly relevant topic for customers who run a GroupWise POA on the Linux or Windows platform. The HTML interface to the GroupWise POA is complete and powerful. It is highly recommended that you enable this feature of the GroupWise POA.

Fill in the IP address or DNS name of the server running the POA, along with a colon and the port number you specified in ConsoleOne or the startup file of the POA. For example:

http://192.168.95.101:8100

You will be prompted for the username and password; use the username and password you specified in ConsoleOne. Figure 8.11 shows the HTTP monitoring screen of a GroupWise POA.

Figure 8.11. The GroupWise POA HTTP monitoring screen

When you are in the GroupWise POA HTTP monitoring screen, you'll see a bevy of information. Figure 8.11 shows only a small part of the information you can get on the POA and the server running the POA.

Tip

When you're monitoring the GroupWise POA through a browser, if you do not remember the HTTP port number, you can also enter through the client/server port. This is usually 1677. The client/server port will redirect the browser to the correct HTTP port for monitoring.

Advanced Configuration

The HTTP monitoring piece of the GroupWise POA has some powerful features that can be enabled if you want, including the following:

• HTTP refresh interval control

• GroupWise client version/release date flagging

To take advantage of the HTTP refresh interval control feature, you need to edit the startup file for the POA. This setting cannot be made from ConsoleOne.

To enable the switch, type the following:

/httprefresh

If you want to have the refresh take place every 20 seconds, the line would read as follows:

/httprefresh-20