Global System Services Corporation (GSS) - The leading provider of email and messaging, directory services, and groupware consulting and professional services

> Support > cc:Mail Post Office Performance

8.4.x

cc:Mail Post Office Performance

Dear "Please Help Me"

First off, the cc:Mail code that runs on DB8 is slower than the code that ran on DB6. Why? Because DB8 is more complex and so is the code that runs on it. There are 3 general components in performance: (1) workstations, (2) networks, and (4) servers.

On the client side, if you're running R6 clients the workstations should be adequate to provide "acceptable" performance since they were adequate before. If you're running R8 clients all bets are off. R8 uses MAPI so there is another layer of APIs between the UI and the post office.

On the network side, R8/DB8 creates more network traffic than R5/DB6. The thing to do is to use a network analyzer to see what's going on on the network. I use Network Instruments Observer and the product has a remote probe capability allows you to monitor networks across switches and routers. The NFT error log is also a good place to look for indications of network problems.

In between workstations and the network operating system (NOS) there is the NOS redirector, for example, the Microsoft 'client' for NetWare. The CCREGMOD utility changes Windows registry settings on Windows 95, Windows 98, and NT to disable performance enhancing settings that cause corruptions of shared file databases (Microsoft Access, cc:Mail, and others). If you have replaced a prior configuration with, for example, cc:Mail R6 or above and Windows 95 running the IntraNetWare client this may perform more poorly than a previous 16-bit configuration.

File I/O loop (client MAPI/MAPI SPI) bug: If you didn't have network problems before you upgraded to R8/DB8, you might now.

With R8 there is an extremely serious problem under NetWare with IntraNetWare client where the cc:Mail product repeats certain file I/O calls indefinitely. The result is about 1000 packets per second per machine caught in a file I/O loop. This will cause almost complete network failure. I wouldn't be surprised if a similar problem occurred
under NT Server.

Although I haven't debugged the code, I believe the problem is actually in the interface of cc:Mail and the cc:Mail MAPI SPI (Service Provider Interface). If so, then the problem could occur independent of the NOS. Of course when networks go haywire NFT errors abound and, just as where there's smoke there's fire, where there are NFT errors there are database corruptions. Take a look at your NFT error log (CCNFT.LG) for clues about what's happenning.

On the server side, it's usually network throughput and disk I/O that kills performance before the CPU does. For a file server dual PII 450's are plenty, even with Windows NT server. What I would ask is whether there are other apps running on the box that might be causing disk I/O or network bottlenecks. Again, I would analyze the network segment that the server is on and do performance analysis of the server itself. For this we need highly detailed information about the server.

Finally, there are cc:Mail configuration settings that that slow down file I/O performance, specifically FAP (File Access Protection) and LAP (Lock Access Protection). LAP is really a diagnostic tool (it detects record locking violations). If you have turned on LAP you have (a) slowed performance, and (b) increased network traffic probably for no good reason. The short answer is that unless you clearly understand what LAP is, why it exists, and how to use it, then DO NOT USE IT.

FAP is a different story. Although FAP does slow performance (by opening and closing files in either read only or read/write modes whenever the code needs to perform a write on the database) it does safeguard the database against certain kinds of corruptions caused by workstations. In theory FAP is never necessary so you can turn it off.
In practice, shrinking the window of opportunity for database corruptions as much as possible makes good sense. I always recommend using FAP.

I hope you find this information helpful.

Ron

--

Glenn Does wrote:

>
>      What about network configuration? Switches? 100Base-T?
>

> Subject: Re: Post Offiice Acess Speed
> Author: "cc:Mail Interest Group" <CCMAIL-L@LISTSERV.OKSTATE.EDU> at
Internet
> Date:    3/12/99 2:56 PM
>
> Sorry, it's on an NT 4.0 server (Dual PII 450's 512MB RAM).
>
> >Garbage Deleted
> >
> >     Hi Ron,
> >
> >     What type of file server OS does your PO reside on.
> >
> >     Alex.
> >
> >
> >Garbage Deleted
> >
> >Hi all.
> >I have a quick question, my (l)users have been whining about speed issues
> >when they connect to the Post Office (mobile and LAN). The complaint is
> >that is not as fast as it used to be (I converted it from DB6, that's when
> >the slowdown occured). The Post Office is DB8 and is currently 2.1 GB. I'm
> >thinking this is the problem, but is it possible to speed up the access at
> >all? Please help me. I'm sick of these calls.
> >
> >Thanks,
> >
> >Ron