Skip to main content

MagicINFO server slow with many screens: what to tune

A MagicINFO server that crawls once hundreds of screens are connected is usually short of Java memory, web threads or database connections, or is doing work you do not need (play statistics, verbose logging). Measure first, then change one setting at a time and measure again.

Symptoms​

  • The web console takes many seconds to open pages, or times out.
  • Screens show as disconnected in bursts, or content downloads stall, mostly at busy times.
  • The server is fine with a few dozen screens and degrades as you add more.
  • runtime\logs\wsrm.log shows errors or timeouts around the slow periods.

Why it happens​

Every screen polls the server every few seconds, so load grows with the screen count while the defaults stay fixed. On a 21.1070 install the service starts with a 512 MB Java heap that may grow to 1024 MB, each Tomcat connector allows 150 worker threads, and the application keeps a pool of 70 database connections plus 20 for the scheduler. Those are the shipped defaults, whatever the size of the installation. For hardware by device count, see the sizing table; this page covers the settings.

Fix​

1. Measure before you change anything​

Open Task Manager (or Resource Monitor) during a slow period and look at three things:

  • CPU: is the Tomcat process (the MagicINFO service) or the PostgreSQL process using it?
  • Memory: is the machine out of RAM and paging? Is the Tomcat process pinned at its maximum heap?
  • Disk: is the disk at 100% busy, particularly the one holding runtime\ and the database?

Then read the tail of C:\MagicInfo Premium\runtime\logs\wsrm.log for repeated errors. A disk or RAM shortage is fixed with hardware, not settings.

2. Change one setting at a time​

Setting21.1070 defaultWhereWhen to change it
Java heap512 MB initial, 1024 MB maximumService properties, Java tabTomcat process sits at its maximum while RAM is free
maxThreads150 per connectortomcat\conf\server.xmlMany screens, console slow, CPU not saturated
wsrm.max_active70conf\config.propertiesLog shows waiting for database connections
Scheduler maxConnections20conf\config.propertiesOnly together with the pool above
pop.enabletrueconf\config.propertiesYou do not use play statistics
Logger levelsmain log at ERRORconf\config.propertiesSomeone raised it for troubleshooting

Java memory. Run C:\MagicInfo Premium\tomcat\bin\tomcat9w.exe //ES//MagicInfoPremium, open the Java tab and raise Maximum memory pool. Keep headroom for PostgreSQL and Windows; never give Java all the RAM. No reinstall is needed. Restart the service afterwards.

Tomcat threads. In server.xml, each connector carries maxThreads="150". Reported guidance is a lower value (about 50) below roughly 300 screens and a higher one (about 300) above roughly 700. Treat these numbers as a starting point to test on your own server, not a rule. Back up server.xml first.

Database connections. The two pools together (70 + 20 = 90) must stay below PostgreSQL's max_connections (100 on that install), with headroom for admin tools such as pgAdmin. If you need more, raise max_connections in postgresql.conf first and restart PostgreSQL, then raise the pool values in config.properties. Raising the pool alone makes things worse: the database refuses the extra connections.

Play statistics. pop.enable = true collects proof-of-play data. If you never use those reports, set pop.enable = false to save database work.

Logging. The main log is already at ERROR on 21.1070. If you find DEBUG or INFO in the main logger lines, set it back to ERROR; verbose logging on a busy server costs disk and CPU.

Connector implementation. 21.1070 uses org.apache.coyote.http11.Http11Nio2Protocol. If an older server.xml still names the APR protocol, switch it. Servers that stalled only while hundreds of screens were active have been reported to recover after moving their connectors to NIO2.

tip

Copy config.properties and server.xml somewhere safe before editing. Both are read once at start, so every change needs a service restart.

3. Restart and measure again​

Restart the MagicInfoPremium service. The web console takes several minutes to answer again (5 to 7 minutes observed), so do not judge the change early. Repeat the measurement from step 1 at the same time of day.

4. When one machine is no longer enough​

If CPU or disk stays saturated after tuning, the next step is to give the database its own computer: see Clustering: separate database, WAS and proxy servers.

How to confirm it worked​

  • The console opens pages quickly at your busiest hour.
  • http://magicinfo.example.com:7001/MagicInfo/openapi/auth?cmd=isMagicInfo answers at once with a build number such as 211070.0.
  • Task Manager shows CPU and memory settling below their limits, and wsrm.log has no repeating errors.
  • Screens stay connected through the busy period.

Checked against MagicINFO Server 21.1070 on Windows, October 2026. Thread guidance is reported, not a measured rule.

Prefer not to run the server yourself? MiCloud hosts MagicINFO for you.

Last updated on