Performance Requirements

The performance requirements for VPOP3 depends on many factors, so we can't give specific details for any scenario.

• Use the Windows Performance Monitor (perfmon.msc)
• Add counters for:
  • Processor → % Processor Time → _Total
  • Memory → Committed Bytes
  • Logical Disk → Disk Transfers/sec → (disk which VPOP3 is installed on)
  • Logical Disk → Avg Disk Queue Length → (disk which VPOP3 is installed on)
• If the “%Processor Time” is constantly above 50% or so, you may benefit from a faster processor, or more cores on the processor (or more processors). Don't worry about bursts to 100% for a minute or so, or while VPOP3 is downloading mail from the ISP, that is normal.
• If the “Committed Bytes” is near, or above, the total amount of physical memory (not page file) which is available on the computer, then you could benefit from adding more RAM to the PC

Interpreting Disk I/O is a more complicated task, as there are many factors.

First, look at the “Avg Disk Queue Length”. If this is pretty constantly above 1 or 2 (or the number of striped disks you have in a RAID 0/10 array) then performance is probably being limited by the hard disks. The Disk Queue is the queue of disk operations that Windows is waiting for. In an ideal world, the Disk Queue would always be at zero, because the disks would be processing requests as quickly as Windows makes them, but this is unlikely to happen in the real world.

So, if the Avg Disk Queue Length is higher than expected, the next thing to look at is the “Disk Transfers/sec”. Different types of disks will be able to process transfers at different rates. Sometimes this is called IOPS (I/O operations Per Second), so you may be able to find information on the rated IOPS for your particular disks/controllers.

A typical 15000 RPM SAS (SCSI) drive will be capable of around 175-210 IOPS, a typical 7200 SATA drive will be capable of around 75-100 IOPS.

If you put these into a RAID 0 or RAID 10 array with a decent hardware RAID controller (not the cheap RAID controllers on desktop motherboards), then the IOPS may be spread across the striped drives, so a 4 drive RAID 10 SAS array would be capable of around 350 IOPS

SSDs (Solid State Devices) are capable of much more , typically over 5000 IOPS, even up to 250,000 IOPS.

As an example, one of our VPOP3 hosted service servers was running with a RAID 10 array on SATA drives, with no BBWC. This encountered performance issues, the IOPS was around 170 IOPS, and the Avg Disk Queue was regularly over 3 or 4 for long periods of time. We moved this to a new server with a RAID 10 array on 15000 SAS drives with a BBWC, the IOPS has increased slightly to 230 IOPS, but the Avg Disk Queue is now about 0.2, and the performance is much greater.

If the Avg Disk Queue is high, but the IOPS is not too high for the disks, then the issue may be disk fragmentation. If the disk is highly fragmented, then the disk subsystem will take longer than normal to process requests, so defragmenting the disk is a good thing to try.

Never use RAID 5 for any database server - such as VPOP3 uses - RAID 5 will be very slow when many small updates are made, such as to database tables

For example, 25 users with VPOP3 Enterprise (using IMAP4) or 50 users with VPOP3 Standard (using POP3)

• Dual core 2.4 GHz Core2Duo or better
• Windows 7 or better
• 4 GB RAM or more
• 7200RPM SATA drives

For example, 100 users or more, with VPOP3 Enterprise (using IMAP4), this is the spec of PC we'd be buying:

• Quad core 2.6GHz Xeon or better
• Windows 2008 or 2012 R2 server
• 8 GB RAM or more
• Hardware RAID controller with BBWC (Battery Backed Write Cache) and 512MB or more cache RAM
• 15000 RPM SAS (Serial Attached SCSI) drives in a RAID 1 or RAID 10 configuration

With this many users, the main limiting factor will be the disk I/O

On a heavily loaded server it may be worth moving the database to a separate physical disk/array from the rest of the PC. For instance, you could have a SATA RAID array for the system and programs, and a (more expensive) SAS RAID array for the database.

Using separate partitions on the same physical disk will slow things down, rather than speed them up, so that is not recommended.

Here are instructions on how to move the database to a new drive