That is a lot of emails/hr how many users do you have?
We have 32,000 users, just recently did a qmail/vpop migration and we don't even do that many mails/hour.
Add RBLS to main.cf to stop blacklisted emails from even entering the queues.
Of the ~1,000,000 connections we receive about 10% is rejected by RBLs
This is a sample of just one of our load balanced standard processing nodes:
1502 Reject relay denied 1.69%
50831 Reject HELO/EHLO 57.04%
26354 Reject unknown user 29.58%
132 Reject recipient address 0.15%
583 Reject sender address 0.65%
489 Reject client host 0.55%
9217 Reject RBL 10.34%
-------- ------------------------------------------------
89108 Total Rejects 100.00%
To speed up amavisd:
- Disable spamassassin outbound scanning
- Disable virus scanning all together
- Use local DNS or an in house DNS server <- this was a big one for us. Dropped our processing times from ~16000ms to less than 3500ms, usual under 1000ms now.
- Relax spamassassin scanning.
*** By the way, the whole mounting the amavisd $tempdir on a ram drive does nothing for performance, at least on our servers it doesn't.
Use more servers.
ie Purchase the iRed Pro edition and use it as your forward facing(client facing) front end for webmail/imap/pop3.
After that grab 4-6 standard/pro iRed installs and place those behind a load balancer.
Load balance your smtp ports only or all port if you like...although that's a pain to manage if something goes wrong.
Configure those servers to remotely connect to the main front end node's mysql database for authentication.
Lastly use a shared storage server mounted to /var/vmail/vmail1 on all iredmail servers so that they all write to the same storage array.
Be mindful that this setup is only redundant as far as SMTP processing goes. You lose that one front end IRed Pro node which hosts the master mysql database and the entire cluster goes with it.
It's best to run failover load balancers, dual master-master mysql backend, dual front end webmail/imap/pop3 iRedmail-Pro nodes, and several remote iRed-standard/Pro nodes connecting to the master-master's DB's for smtp processing. Lastly dual DRDB(difficult to setup, difficult to manage, unknown small file performance)/glusterfs(easy setup, very slow with small files) failover storage nodes....or just run regular NFS shared storage(easy setup, fast, no redundancy).
With the above config you'll have 4-6 servers all processing mail simultaneously. This will allow you to have both speed and filtering...
Keep in mind there is a lot of configuring to do.