To diagnose issues I’ve changed from PHP7 FastCGI to CGI. But looking at a page rendering phpinfo(), I don’t see where it says explicitly which mode is being used. Server API shows “CGI/FastCGI”. Aside from looking in the panel and trusting the setting, how can I be sure about the mode?
I’ve read that there can be different permissions requirements for CGI versus FastCGI. I understand that resources are accessed by a different user depending on the mode. But I can’t find a source to verify any related details. Any references?
Is there any DH script/bot that can run through a site to tell us about permissions issues? (I know, depends on the application.) Without doing a manual check and hoping I find any bugs, I have no idea if a blanket change on the site will work or disable parts of the site. (644 files, 755 dirs).
I’m hoping/assuming that FastCGI is the right choice for a domain with WordPress on a DH shared account. Any comments about this specific configuration?
Is there any server performance indicator that we can look at to tell if we’re doing better or worse with FastCGI vs CGI?
I had to research this myself as I didn’t know: if you’re running CGI, in phpinfo() output on under “Environment” you’ll see a lot of variables, the most important one is “REDIRECT_HANDLER”. If you’re running fastCGI you’ll most likely see only “PATH”.
not sure what that thread was about… if you have access issues those will clearly be marked as such in Apache’s error.log. Until you see 404 errors and evidence in error.log, I woundn’t worry about that.
Those issues show up in error.log, I don’t think such script would be very valuable. What you need to worry about are files and directories that are too open. For these, you can use find:
will show you all the files and directories that are writable to all (which is not always necessary).
FastCGI is usually the best choice for WordPress. CGI is only useful when your main use case involves uploading large files via PHP: in such cases, FastCGI may timeout while CGI processes may not.
You can run a http stress test tool to your site and check the response time. Run the test using both CGI and FastCGI configuration with a simple tool like autobench http://www.xenoclast.org/autobench/ … Have a go at it and let us know what you find out.
@smaffulli - Just a ping here to thank you for your thorough response. I have been working on several WordPress sites in my account, and now that they’re fairly stable I’m coming back to this topic. It’s all great info here and will take a while to review so I’ll post back later.
The note on FastCGI possibly being slower than CGI with large files could be a clue to a chronic problem. I am a member at WPMUDEV which provides awesome plugins, themes, and support services for WordPress. One of their services is an updater that (unfortunately) hits many sites simultaneously with plugin updates. It’s possible that they’re slamming my sites with zip files, rapidly causing my resource usage to ramp up, and either FastCGI does a timeout or the DH procwatch starts to kill them off.
Is there anything that I can do to self-throttle connections like that to keep these auto processes from doing their thing?