Fixing critical Roundcube Webmail slowness

If your server has spare CPU/RAM but Roundcube takes 30 to 60 seconds per action, you are likely facing a logical bottleneck (IMAP, DNS, session lock), not hardware shortage.

1) Typical symptom: healthy host, slow webmail

Common metrics during incident:

• low load average
• high CPU idle
• near-zero iowait

Yet Roundcube logs show repeated session conflicts, IMAP handshake failures, and external request stalls.

2) Most common technical causes

A) Database: Duplicate entry ... for key 'PRIMARY'

Slow response can trigger duplicate requests, causing session/cache insert contention and visible UI freeze.

B) IMAP: Empty startup greeting

When Dovecot enforces low per-IP limits and webmail traffic comes from localhost, connection caps are hit quickly and new IMAP sessions fail.

C) External timeout path (DNS/API/fonts)

Remote resource fetches can block page rendering when resolver/network path is unstable (VPN, overlay networks, slow DNS).

3) Step-by-step remediation

Step 1: tune Dovecot connection limits

In the applicable Dovecot config:

mail_max_userip_connections = 20
remote 127.0.0.1 {
  mail_max_userip_connections = 200
}

Restart service:

systemctl restart dovecot

Step 2: force IPv4 loopback in Roundcube

In config.inc.php, avoid localhost:

$config['imap_host'] = '127.0.0.1:143';
$config['smtp_host'] = '127.0.0.1:587';

This avoids ambiguous hostname resolution and unnecessary IPv6/DNS paths.

Step 3: remove external rendering dependency

In config.inc.php:

$config['standard_fonts'] = true;

This minimizes delays caused by remote font fetch.

Step 4: reset session/cache state

If duplicate-entry errors polluted runtime tables:

mysql roundcube_db -e "TRUNCATE TABLE session; TRUNCATE TABLE cache; TRUNCATE TABLE cache_index; TRUNCATE TABLE cache_messages;"

Step 5: restart persistent PHP workers

LiteSpeed keeps long-lived workers that may hold old config:

killall -u webapps -9 lsphp
/usr/local/lsws/bin/lswsctrl restart

Critical Roundcube slowness is usually a concurrency/waiting problem, not raw CPU/RAM limits. Forcing local loopback, increasing local IMAP tolerance, and removing external timeout points restores stable webmail performance.

This post is licensed under CC BY-NC.