PHP vs CGI

[chrison600]

Hi all,

I currently use a PHP script on a "classified ad" site. I'm somewhat happy with it, although one major reason I chose it was because the CGI alternative was twice the money. Considering some of the difficulties I've had with the PHP script code quality and company, I am thinking about changing (ouch) and would like your feedback on PHP vs CGI solutions, assuming all else equal.

Thanks!!

Chris

[Sualdam]

On the whole, it depends on the application, but assuming 'all things equal' like you said, configuring CGI scripts is usually much more difficult. That's been my experience.

Personally, I don't think there's much to choose between them if we're talking about a ready-made script (allowing for configuration difficulties).

Writing or modifying an app is another thing entirely, of course :) PHP is much more straightforward in that respect.

That's just my 2 cents.

[alhannah]

CGI is basically a way of interfacing with the web server, so, it could be in a variety of languages (technically) including C/C++, Java, Perl among others -

Usually, though, I do find that most people consider "Perl" the defacto when speaking about "CGI"... however ... the performance between the various languages and Perl greatly differs.

Here's Perl's strong points :

- Powerful scripting language
- Powerful matching (regexp)
- A wide variety of commands available - including file saving, executing OS commands, etc - you can go down to server administration with Perl if you like

And the weak points :
- A wide variety of commands available - including file saving, executing OS commands, etc - you can go down to server administration with Perl if you like
- EACH request to the Perl script generates a new instance of Perl in memory - and the Perl Interpreter is not memory-friendly.


PHP on the other hand kills a lot of the security risks that Perl has- so- it's safer in a sense. If the CGI was written by someone compotent (or halfway decent) then it should be secure, however, many a webserver has been defaced in the past due to shoddy Perl/CGI ... so beware ... if you are accepting a third party CGI, make sure the author is reputable. If you are doing the CGI yourself - read up on escape characters & data formatting to potentially save yourself trouble in the future.

( For the record, I do Perl and not PHP - my "large job" choice over Perl is JSP/Java. I don't know why, but the "personal" part of "PHP" just drove me away from using PHP - although it is very well suited for professional applications. The "personal" aspect is a sort of reference to the way PHP kills a lot of Perl's potential security risks for the ISP. And for anyone who has read "ugly unix-guru perl", that's not my Perl style :) - I do a little of that old-style Unix obfuscation, but not much. Most of my code is in pseudo-English. )

I also hear that PHP's code is more intelligible than Perl, and if you're dealing with some Regexp guru's Perl - or one of those "old-school-UNIX-people" programs ... then you have a nightmare on your hands (configuration & readability-wise.)


Perl is, in my opinion, good for smaller to medium sites (OR a big site with lots of cash to burn on CGI servers) - you need to make sure your codes are fine tailored to the need. From the looks of what you were describing, you'd probably use the CGI for a lookup or such. If the CGI makes static pages for each listing (assuming a classified) then it should be OK until the site gets too big. If it stores each listing in a database, then you'll end up paying too much for bad performance.

On a side note - your ideal choice would be a database server or a daemon running on the webserver that serves data per-request to a lightweight JSP or something similar. Even if you had a Perl/CGI connecting to a MySQL database server, it would still make the webserver's performance suffer - since no matter what - you'll always call up a new instance of Perl to send out the DB requests.

So - in the long run - I'd say give the PHP a fixing if possible - if that is not a doable thing, then see if the CGI can be seen in action.

If you can't verify that the CGI is a good option, I'd stick with the PHP - and shore up any perfomance/usability issues as you go along. It works, and if it's serving you well, keep using it. But, if you're not using it already - or have already chosen a newer, alternate method of information processing - then stick with the newer method.

Just my $0.02.