| |
 |
 |
 |
 |
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).
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
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?
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?
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.
4. Availability
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.
3. Ease-of-backup
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.
Hosting Tips
1. virtual vs dedicated
From time to time we meet smart users who are trying to run high-traffic systems
on virtual hosts. Sometimes they wonder why things aren't working their way.
The answer is simple – usually buying virtual hosting you get a part of server
with about 100, 200 or more other members. And the whole company will share
resources of one computer and one network connection. Good for small or
static sites with quiet neighbors. If you wanna have high-traffic system
and have full control over your site – choose a dedicated server.
The other problem is security: very often your virtual neighbors are able to
read your files, so if you need high security level – your choice is dedicated
server again.
2. “High speed connections”
Did you ever read “Unlimited traffic” or “Unlimited 10 Mbit connection”
(or even 100 Mbit)? What does it really mean? The truth is you’ll not get
10/100 Mbit connection to Internet – these numbers characterize only
capacity of hardware installed on your computer, but not real connection
speed. Real 10 Mbit connection would cost you thousands of dollars/month,
do you really believe that you’ll get it for $100 only? The truth is that
if you don’t lease a separate connection you will be sharing your webhost
providers’ connection with their other clients. Really you can hope you’ll
get 200-400 kbit connection max on dedicated server. Refer a table below
to see what real Internet connection speeds are. We did not investigate
what are the current prices for high speed connections, but just for your
info – the cheapest T1 solution is $500-$1000 and higher.
Now let’s count what amount of traffic you can generate. With 400 kbit
connection you’ll make 124 GBytes of outgoing traffic/month. Incoming
traffic is usually much less than outgoing, so you can expect not more
than 150 GB/month (theoretically 250 GB).
The traffic expectation for T1 line would be about 560 GB (970 GB max)
T1 – 1.5 Mbps
T3,DS3 – 44.7 Mbps
OC3 – 155.5 Mbps
OC12 – 622 Mbps
OC48 – 2.4 Gbps
|
|
|
|
 |
|
 |
|
 |
|
|
|
|
| |
 |
| |
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."
David Prahl
"Thanks again.
Your support has been totally awesome!
have a great weekend."
Russ Johnson
"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!"
Peter Rogers
www.investorsdashboard.com
Click here to submit a testimonial!
|
|
| |
|
