My experience, suExec + FastCGI + opcache VS mod_ruid2 + DSO + opcache

[DrPrez]

Hello everyone,

I'm an old but new user of CPanel. Used to run CPanel on our servers many years ago and now we recently got a cloud VPS and chose to go with CPanel once again.

Our company has developed a control panel for our clients with an API where client websites gets live content from the control panel. For this we chose the PHP framework Laravel. For those of you who are familiar with Laravel, you know it's pretty heavy framework.


Setup
CentOS 6.5
Apache 2.4.x
PHP 5.5.x


The problem

On a brand new VPS, our biggest problem was time to first byte (ttfb), a single request to our API would be delayed anywhere from 500-1000ms with suExec + FastCGI + opcache (and Laravel optimized). As you can imagine this was unacceptable.

We even tried to make a simple "Hello World" HTML file, renamed it to .php and this alone caused the ttfb to go from ~25ms to ~130ms ..


The solution

After trying tons of different settings we noticed that DSO was giving us the best results but was not secure enough with suExec, so we decided to try mod_ruid2 + DSO + opcache and the results are amazing.

The "Hello World" test file went from ~130ms to <40ms
Our heavy API went from 500-1000ms to <100ms


That's it, I hope this info helps someone.

 

[cPanelMichael]

Hello

Thank you for taking the time to share those results here. I'm sure other users will find it helpful.

 

[DrPrez]

How to test Time To First Byte

Here are a few links to online tools and also screenshots of how you can test your TTFB.

Note: Repeat checks should have a lot lower TTFB.


Websites

- Pingdom
- WebPagetest
- ByteCheck


Browsers

Firefox


Chrome


Internet Explorer

 

[maqsium]

Hello,

I also have same issue of time to first byte, we moved our websites from AWS to dedicated server which is equipped with WHM.
With AWS previously, we had TTFB of less than 700ms for a heavy website, but after moving to new server with Apache, it is taking lot of time.

My current settings are:
Apache 2.4
FastCGI (mod_fcgid) enabled
PHP 5.5

For me also, a simple hello world php file takes around 106 ms which is way high. Kindly suggest a work around for the issue.

Regards,
maqsimum

 

[sonicthoughts]

I agree that this is great performance, but unfortunately, mod_ruid2 still does not support caching (memcache!) which really kills performance. Hoping CP will address this soon.

 

[cPanelMichael]

mod_ruid2 still does not support caching

To note, the corresponding feature request is found at:

memcache / cache and mod_ruid2

Thank you.

 

[Sascha H.]

We are using cPanel & WHM for the very first time and is installed with CloudLinux 7.2.

The installment is done on a dedicated HP ProLiant DL360 Gen9 server. It has 64 GB RAM and 2x Intel 6-Core CPUs and 4x600GB SAS HDD RAID Level 10. The BIOS is tuned for maximum performance and setup using HP best practices. On top of it there is HP SmartCache installed with a 400 GB SSD.

My experience having a default installment of CloudLinux+cPanel+CageFS+suPHP+PHP-Selector+EA3 installed, whatever PHP-Application I use my TTFB always has about 2-6 seconds which in fact is a serious issue. I had the installation on a small VPS with 4 GB RAM and got the same results using Wordpress, Typo3, phpBB etc.

What I see during the first request is, the user process is spawning and then does nothing for about 3-4 seconds, then CPU gets fully used and the page is rendered. But once loaded and you hit F5, the page loads imminently IF the user process is still available.

I tried LiteSpeed instead of suPHP, same result. I tried FCGI, same results. Then after migrating from EA3 to EA4 and MultiPHP, the TTFB reduced to 1,5 seconds which is on a heavy coded Typo3 presentation an avg. good result if the page wasn´t rendered / cached by Typo3 previously.

I am really clueless as to why a baremetal server has such problems. The system is fabric new, no errors nothing. Whether it is CloudLinux or PHP-Selector but I expect a super fast server. The CL-guys are clueless as well.

Could it maybe an IPv6 problem in PHP? Our infrastructure is built upon IPv4 only so my guess might be PHP tries DNS resolution over IPv6 first, gets a timeout after a few seconds and then finishes through IPv4. It´s just a guess.

 

[UHLHosting]

@DrPrez you think this setup you have there mentioned would enhance my TTFB for my sites? Right now I use FPM + Opcache + CGI