Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

migrated from Aug 3 '11 at 7:28

This question came from our site for computer enthusiasts and power users.

up vote 2 down vote accepted

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.

share|improve this answer
i would go to this answer. nice and straight to the point. – sheeks06 Aug 4 '11 at 4:17
reads like a rephrased version of mine :) – akira Aug 4 '11 at 6:19
yes. this saves me the time in asking more questions :P. – sheeks06 Aug 4 '11 at 10:16

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'.

share|improve this answer
now i have an average of 1.5k visits a day... processor reaches 70% in 4 servers... are these reasons enough? – sheeks06 Aug 3 '11 at 6:55
thats up to you to decide. you have 86400 seconds a day and 1500 visitors. plenty of time, if they are distributed equaly over the day. – akira Aug 3 '11 at 7:27
Just wondering, but if you have a clustered server, would it be better to use CGI, since you can easily devide processes between your nodes ? – Lucas Kauffman Aug 3 '11 at 7:42
divide processes through what? sorry i'm a complete noob on this. fastcgi is a lot less process hog though...(i assume..) – sheeks06 Aug 3 '11 at 9:28
he meant: if you have already a cluster of 4 servers, are you able to share the load across the 4 servers (instead of having one server handling all the traffic). – akira Aug 3 '11 at 9:39

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).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.