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.”
Here we’ll try to explain why these rumors are rumors only…
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).
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.
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.
Did you ever notice that PHP-developers are the first who say “PHP rules!
It’s easy-to-everything” ?
Sure, PHP is a good programmers’ choice… for a
programmer who wants to deliver the working product ASAP, but who does not
care for anything more than to deliver demo version or one-server version.
Yes, PHP is easy-to-write, but is it easy-to customize?
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
If you browse through the PHP script's requirements and notice that the script needs
"Zend Optimizer" or "Ion Cube Loader" applications installed on the server, this
means that the script code or parts of the script code is encoded and requires
these applications to decode on-the-fly. Encoded script code can not be edited,
which limits you in terms of customizability of the script in present and future, should
you require modifications or added functionality.
Sure PHP is as wide-spread as Perl, but let’s be realistic: different webhosts
have different PHP versions with their own settings. Providing PHP versions of
our scripts we deal with about 10 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.
Flatfile vs MySQL
Here we’ll try to answer some common questions about choosing between flat
file databases and relational databases (MySQL is the most used RDB)
1. Cheap hosting
Many users prefer to save a couple of bucks purchasing hosting packages
without any database support. We must disappoint you: usually you can get
the same, for the same price but with MySQL. Commonly, this cheap solution
without database would be either a starter package without many other
features, or some old server with old software.
2. Database benefits
Generally there are 3 main benefits of using databases: data integrity, indexing and caching.
Data integrity: multiple user access to flatfile won’t be as safe as database access.
Also, databases allow executing several read/write/update operations simultaneously
preventing data loss or corruption. Also, databases usually contain tools that allow
you to check and restore data.
Indexing: indexing is a very powerful tool that dramatically increase search and access
speed. That’s the main factor in increasing performance of databases.
Caching: Caching is another tool to increase performance. This effect is achieved
by storing a part of common used data in servers’ memory.
There is a common myth that flatfile database is easier to backup. Sure, you can
upload files by ftp, but that can be not an easy and quick task when you have
thousands of files to download. Databases always provide you tools that allow
you backup/restore data, so this won’t be a problem for you too.
4. Common traps
There are several traps you can get in using flatfile databases.
Main traps are: accessing large file, big amount of created files, file locking.
Also there are traps using databases too: non-indexing and unmotivated usage.
Accessing large file: usually your script must open a big file and read it from the
very beginning to very end (or to the record you’ll need). That’s a lengthy operation
if the file is large.
Big amount of created files: that’s the most serious trap. It occurs often – you have
individual file for your members’ profile or for keywords or for some other data.
The result is always the same: you have a several thousands of files, each of them
is small. The developers of your script will tell you smth like that: “What for do
you need database? You have too little info with every profile/keyword/etc”.
But really, they do not care that only opening of a file from a directory
with 1000 entries is a lengthy operation, since your operation system must scan
through all filenames in directory until it would find file you need.
The other big problem is that opening file you’re using system resources –
that means all other services would run worse on your system. It’s very
sad but a lot of products (and sites) still use flatfiles with that trap.
The other problem is that you’ll realize problems when your moneyback or
support periods are gone.
File locking: here we can find 2 problems: if you’re using file locking on big
file that means your other users won’t be able to access it. Unfortunately not
all programmers use file locking, so the other problem would be simultaneous
writing to the same file – results are unpredictable.
Non-indexing: Sad, but true – some products use MySQL, but do not use indexing
abilities. Sure, you’ll get other benefits, but as it was said above – indexing
is the main factor influencing productivity.
Unmotivated usage: That’s just an opposite for using flatfile – some developers
prefer to store everything, like templates, large files/images, script params
in database. Unfortunately, these steps would only decrease performance of your system.
We recommend following hosting companies which are fully compatible:
|Do you need these scripts in PHP?|
Read here why we use Perl!
|A flat file database is enough?|
Read here why we use MySQL!
|Puzzled about hosting?|
Read here what we recommend!
|READ MORE TESTIMONIALS HERE!|
"Oh my god! You are awesome.
I am a customer for life now.
Sincere thanks and have a great day."
Your support has been totally awesome!
have a great weekend."
"Thanks again for the clear answers. With your product, the documentation was outstanding
and my follow-on questions were handled
promptly and effectively. Your product and service is outstanding!"
Click here to submit a testimonial!