3

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?

Improve this question

3 Answers 3

Reset to default
2

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.

Improve this answer
3
  • i would go to this answer. nice and straight to the point.
    – gianebao
    Aug 4, 2011 at 4:17
  • reads like a rephrased version of mine :)
    – akira
    Aug 4, 2011 at 6:19
  • yes. this saves me the time in asking more questions :P.
    – gianebao
    Aug 4, 2011 at 10:16
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'.

Improve this answer
5
  • now i have an average of 1.5k visits a day... processor reaches 70% in 4 servers... are these reasons enough?
    – gianebao
    Aug 3, 2011 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, 2011 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, 2011 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..)
    – gianebao
    Aug 3, 2011 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, 2011 at 9:39
0

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

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .