LiteSpeed Cuts RAM Usage by 95% on Shared Servers https://www.litespeedtech.com/images/logos/litespeed/litespeed-logo.png 2019-10-08 18:43:23 See how LiteSpeed Web Server helped Synergy 8 pave the way for exponential growth with minimal server impact.

LiteSpeed Cuts RAM Usage by 95% on Shared Servers

Caching paves the way for exponential growth with minimal server impact

 The Challenge

  • Average server has 160 separate websites, averaging 10 req/sec, peaking to 100 req/sec.
  • Traffic is PHP heavy.
  • suEXEC needed for security, but can cause very high RAM usage.
  • Exponential growth already under way.

 The Solution

  • LiteSpeed Web Server 2-CPU license.
  • PHP suEXEC Daemon mode with shared opcode caching.
  • RAM usage immediately decreases from 40GB to 2GB.
  • Addition of new users does not add noticeable increases in RAM usage.

Synergy 8 is a cloud-based platform for managing your online presence. Features include content management (CMS), e-mail marketing, customer database (CRM), and e-commerce. Our application servers serve a lot of dynamic content (PHP), moderate amounts of static content, and very little video. We believe that performance is paramount to usability, so we are prepared to invest in the best software and hardware solutions available. All of our clients share the same PHP code base on a "per branch" basis, so shared opcode caching is very beneficial for us.

Our initial configuration was Apache+DSO+PHP. At the end of April 2013, though, we switched to Apache+FCGI+suEXEC for security. We upgraded to PHP 5.5 and moved from APC to OPcache for our opcode caching. We used generous opcode cache sizes, as we like to take advantage of our servers' high memory capacity. We were not aware, though, of the insane implementation of FCGI PHP suEXEC— there is no shared opcode cache. This caused our committed memory to spike. FCGI also spooled up processes leading to dangerously high RAM usage (see graph at right). Each new website added about 300MB of RAM, with almost a 1GB commit. As we grew with this unscalable approach, we experienced a couple of crashes , primarily in the form of Linux watchdog timeouts — a classic “out of memory” event. This would happen during our most critical/peak times as Apache would spool up additional workers and PHP processes. We did not want to leave Apache, but enough was enough.

In August 2014, we switched to LiteSpeed+suEXEC Daemon mode. With suEXEC Daemon mode's shared opcode caching, we immediately reduced RAM usage from 40-50GB consumption + 100GB commit to 2-3GB consumption + commit. Our services run faster, mainly due to this freed up RAM now being utilized for disk caching.

Our bottleneck has been RAM usage for quite some time now due to suEXEC. This scalability, reliability, and performance issue was solved with LiteSpeed Web Server. The other factors (CPU, etc) are not a problem at present for us. We did not see any real difference in CPU usage between Apache and LiteSpeed, though this is probably due to our workload mainly being dynamic PHP, rather than static files. Thanks again for your product. It’s taken a great deal of pain away.

LSWS's combination of PHP suEXEC and opcode caching slashed RAM usage for Synergy 8, while keeping top-of-the-line performance. Do you have runaway RAM usage? Interested in opcode caching with suEXEC security? Read up on LiteSpeed's unique suEXEC Daemon mode.

September 16, 2014

  • Load Graph

    memory usage
  • Server Environment

    Dual CPU x5690 (2x 6 core) 3.46 GHz
    96 GB RAM