September 16, 2014
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.