Performance

From Halon, SMTP software for hosting providers
Jump to: navigation, search

The Halon SMTP software is highly efficient, and can handle incredible amounts of e-mail traffic. For example, our reference system (Dell with two Intel Xeon E5-2630L, 64 GB RAM and PERC H710P SAS RAID) can handle

Test Messages/second
Scripting only, reject, without history 10.000
Delivery performance 4.000
CYREN RPD 3.000
SpamAssassin (opportunistic, bypassed if too slow) 150

and because the clustering scales linearly, the throughput is proportional to the number of nodes.

Optimising performance

  • Hardware considerations
    • Use fast disk systems; SAS RAID or SSD
    • The more RAM the system has, the faster it becomes (thanks to disk/database caching)
    • Make sure the storage disk is at least 10 GB; some optimisations (for example database checkpoint segments) depends on it
  • If you have many "backend" (email storage) servers, you can achieve higher throughput and better resilience by
  • Increase overall throughput by
    • Run globalview() or other IP reputation service in the RCPT TO or IP script
    • Use CYREN's RPD instead (or at least before) SpamAssassin, because RPD is much faster
    • Instead of anti-virus engines, use DLP to block executable file extensions (even in ZIP files) using options ["stop_on_match" => true, "timeout" => 10, "recursion_limit" => 0]
    • On a hardware with many, fast CPU cores SpamAssassin performance might be increased by raising antispam_sa_processes
    • Many high-volume hosting providers need to disable SpamAssassin DNSBL lookups
    • If you have many listeners (mail_server__) on different ports but with the same settings (flows, etc), consider having just one listener with multiple ports (25,2525,587) instead, because the number of available threads are divided between listeners
    • For higher reject/defer performance, disable mail_internal_history and configure external logging via syslog or the end-user system instead
    • If you run http() frequently (possibly for queries or logging), consider using the background flag to dispatch queries in the background. If that is not possible, avoid HTTPS (if the network is already trusted), and if you need encryption, install the certificate locally on the PKI page instead of relying on the ssl_default_ca option