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?

score 2 · Answer 1 · answered Aug 03 '11 at 06:23

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

answered Aug 03 '11 at 06:23

akira

531
2
11

now i have an average of 1.5k visits a day... processor reaches 70% in 4 servers... are these reasons enough? – gianebao Aug 03 '11 at 06: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 03 '11 at 07: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 03 '11 at 07: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 03 '11 at 09: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 03 '11 at 09:39

score 2 · Accepted Answer · answered Aug 03 '11 at 12:34

2

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

for conserving resources where the box is serving up a very small number of dynamic pages
where you need to invoke functionality using a different uid (e.g. via suexec).
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.

answered Aug 03 '11 at 12:34

symcbean

21,009
1
31
52

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

score 0 · Answer 3 · answered Aug 03 '11 at 13:40

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

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

3 Answers3