php >< cgi scripting

[seabuggz]

New to the scene so don't shoot :bemused:
I'm looking to buy a classified ads program to implement into my web site. There're programs that work with php straight off and others that work with cgi scripting. Question ... how is the data handled between the user interface and a MySQL database using the latter and which program is faster?
Would appreciate your help!
Greets 😃

[bpat1434]

From a user standpoint, the only noticable difference is the extension of the file that they view. Everythign looks the same. I haven't noticed a difference.

As far as the database and efficiency, that all depends. What type of databases are you going to be using (MyISAM) and how much data is going to be stored in there? This forum is php mySQL based, and it's not slow at all. Of course it's optimized for it, but if you are going to purchase a product, it should be optimized as well.

What will slow the database down is if you have a lot of information flowing from it or stored in it. From what I can tell, the PHP and CGI work with the database at about the same speed.

You may wish to read this if you have time:
PHP vs. CGI
PHP vs. CGI <-- Same as above, but we're linked on it, so I think they merit a link too.
Interesting take on CGI/PHP
Another VS. Topic

~Brett

[seabuggz]

Found this on a developer's web site and thought his point of view was pretty interesting.
Keep up the good work! Greets 🙂

---

PHP vs Perl

We often receive requests to get our products written in PHP. When we ask “why?” the answer is usually “I heard or read somewhere that PHP is much better/faster/more stable/more secure etc.”

1. What is faster
   Usually people confuse PHP and apache mod_php module. In this language combat one must compare normal PHP preprocessor against normal Perl interpreter (not mod_php vs Perl or PHP vs mod_perl).
   Telling you the truth here… PHP is slower.
   Next we’ll try to explain which benefits mod_php can offer you.
   First of all when you run mod_php, no PHP or Perl processor/interpreter is loaded in memory, which would give you a real benefit of about 0.01 – 0.02 sec per process when using Perl and 0.7 sec (!!!) using PHP. Second benefit is permanent database connections. Normally your mod_php script won’t connect to database, this saves you 0.13 sec using Perl/DBI and 0.2 sec with PHP.
   During our tests (sleep(1)) we observed that average memory usage for PHP script is 3.5 times higher than Perl (0.7% vs 0.2%) while CPU usage for PHP script (1.3%) is more than 13 times higher than Perl (less than 0.1%). It’s well-known that PHP needs more resources than Perl, this we just proved in our small test.

2. Stability
   Here you can’t have 2 opinions – Perl is more stable than PHP. First, stable Perl 5.0 version is developing since 1995, the most current versions (5.6.0 and up) are developing since Mar 2000. PHP 3.0 appeared in 1998 while most popular 4.0 stable version appeared in May 2000. Since spring 2000 we got more than 15 stable releases of PHP4 and only 6 stable releases of Perl. If you view changelogs you’ll see that PHP changes are mostly bugfixes, while Perl changes are mostly feature enhancements. Another problem is that PHP versions are not 100% backward compatible, but we’ll discuss that below in more detail.

3. Ease-of-use/Customization
   PHP is a good programmers’ choice… for a programmer who wants to deliver the working product ASAP. Yes, PHP is easy-to-write, but is it easy-to customize?
   Question:
   What is easier for you, to make customization in general-type template like

Your score is: [[USER_SCORE]]

or make PHP-embedding like

Your score is: <?php echo $user_variables[‘user_score’]; ?>

Do you want your own programmer who will be making your desired customization to find 2 strings of code between kilobytes of HTML, or do you want to call for programmer or product support every time when you want to change your site layout only because you think that your designer can corrupt the script code?

4. Availability
   Sure PHP is as wide-spread as Perl, but different webhosts have different PHP versions with their own settings. Providing PHP versions of our scripts we deal with several different versions of PHP, some hosts were even running PHP3. Unfortunately, different PHP versions are not 100% compatible, so neither you, nor developer can be absolutely sure that your script would be working after you’ll transfer it to another webhost.

The next problem for you can be PHP configuration. Since PHP is not as universal as Perl most number of features can be switched on or off not in your script, but during PHP (or mod_php) compile time, or in ini-file, or in apache configuration files. Usually you would be unable to do this on virtual servers. For some reasons you may not want to perform these operations on dedicated server too. What you may theoretically loose: file uploads, error tracking, include directories support and many others.
One may ask about Perl modules that are needed by the scripts, but may be unavailable at web server. The answer would be easy: frequently-used Perl modules (like CGI, LWP etc) often come with Perl distribution, so you may find them on near 100% of servers running Perl. Webhosting companies running MySQL on their servers usually have appropriate DBI modules loaded too. Moreover we noticed that webhosting support prefers installing Perl modules rather than recompiling software or changing configuration files.

---