Are there benefits in using CGI in a large scale Apache2 server or should I just use FASTCGI?

Question

I have a web product done in PHP that theoretically should support a lot of users. Problem is, I just left the apache as it is and found out its just running as CGI. Is this very wrong and I should do it in fastcgi or just leave it as it is?

Answer 1

The only valid reasons for using CGI in preference to fastCGI or an apache module are

1. for conserving resources where the box is serving up a very small number of dynamic pages
2. where you need to invoke functionality using a different uid (e.g. via suexec).
3. where your processing engine (i.e. the PHP interperter) is very, very flakey or in the process of undergoing multiple changes - and then only for system testing

If none of these apply then your website will be much slower and require more resources to operate since the OS needs to start up a new process for each request.

Answer 2

just understand the difference between the two approaches:

with cgi the webserver starts a new process (the script you want to create the response for the browser) for each request. (if noone visits your server, no processes are idling around).

with fastcgi you have a bunch of up-and-running instances of that wanted 'scripts'. (this approachs saves you the time of launching new processes, but you have to keep the bunch of up-and-running instances under control, google for php-fpm).

what to choose now: if the number of real visitors match your 'theoretical' expectations AND you experience bad performance: think about switching from 'cgi' to 'fastcgi'. you should read into 'fastcgi' anyway to deepen your skill set. but no action is (hard) required as long as the number of users is quite small and the speed is 'ok'.

Answer 3

What is "large scale"? For some it's 10 million pageviews a month, for some 10 million pageviews an hour. What is it for you?

That "1.5k visits a day" you mentioned in a comment certainly is not a large number and the traditional CGI will work with that kind of traffic without any problems. Depending on the web applications run on your systems the traditional CGI will probably work with a traffic one hundred times busier than your current traffic.

But let's forget the numbers.

FastCGI is faster than traditional CGI, because there are already those already running worker processes waiting for new requests to handle. In traditional CGI every request spawns a new process. In theory FastCGI might help you in site response times already, completely depending on if the current bottleneck is your web application (for example, actual bottleneck being database calls).