The current setup seems to be only using nginx as reverse proxy in front of apache/php-fpm.

Right now requests seem to go this way nginx->apache->php-fpm.

We'd like to test with apache completely removed and nginx->php-fpm direct.

We'd like to have a nginx -> php-fpm setup for generating dynamic content on uncached pages for faster performance.

We are able to get twice the page loading speed from a direct setup on Linode with identical specs with Nginx used for php-fpm than the Thunderstack use of Nginx only as a reverse proxy and Apache for php-fpm dynamic content.

When a customer is logged-in to an ecommerce site much more of the content is served dynamically and cannot be cached - so all the caching in the world can only give performance to the static content.

Whereas, using Nginx & php-fpm for the dynamic content generation will give much needed additional performance for the dynamic conten webserver.

Out tests also showed no regressions in functionality with WP/Woo . and 160+ plugins.

While I'm glad to finally have the ability to upgrade to PHP 7, it's very frustrating and time-consuming to have to clone every application in order to make that happen.

That means new IP addresses, new FTP user accounts, new IP Whitelisting setup, SSL certificate setup, reconfiguring the SMTP mail add-on...and of course, DNS propagation time. What a hassle!!

Please develop an auto-migration tool to move an application (or server) to a new server, rather than clone it, keeping the abovementioned settings intact.

This would also help for Digital Ocean server downgrades -- rather than cloning to a new (smaller) server and having to reconfigure everything, we could just migrate to a new server keep all the old settings intact.

There is an issue on servers configured by Cloudways, in which the PHP-FPM log buffer (error msg length) is set to 1028 bytes. This is too short for many errors messages generated by Wordpress.

It results in many entries of:
"Message":"AH01071: Got error 'the log buffer is full (1024). The access log request has been truncated.'"

In the PHP error logs views in Application Manager. So rather than seeing the actual error, you end up just seeing this message. Which is, obviously, very unhelpful.

Apparently it's due to the setting of log_limit setting in PHP-FPM, complied with Nginx.
You can read about this here: https://serverfault.com/questions/256459/nginx-php-fpm-long-log-lines-get-truncated

PHP-FPM will need to re recompiled with a patch. See here https://forums.freebsd.org/threads/howto-stop-nginx-php-fpm-from-truncating-your-stack-trace-error-message.56543/

Anyway... I found a workaround solution is to add the following to the PHP Advanced Settings on the Application:

phpadminvalue[logerrorsmax_len] = 2048

Once that is added, property (and useful) error messages are now accessible in the error logs.

I suggest Cloudways either compile PHP-FPM with a higher log_limit, or implement the PHP change I've mentioned, by default on all applications. This would save the customer from having to deal with this issue.

Regards,

Jonathan

Enabling "Objects cache" option slows down the admin panel several times and does the admin job uncomfortable. This is confirmed as the objective admin panel page load time, and when I tested perfomance with the P3 plugin. Disabling this option or use "Database cache" instead of "Objects cache" returns the speed of the admin panel at an acceptable level.

I use the W3TC plugin to cache the site in full accordance with your guidelines. This problem constantly exists as in the Cloudways WordPress Cloud Platform and in the Cloudways WooCommerce Cloud Platform.

It seems that the problem requires a more detailed analysis. Fix it please.