Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Perl and Infiltrating PHP Workplaces

by TedPride (Priest)
on May 24, 2006 at 05:04 UTC ( [id://551275]=note: print w/replies, xml ) Need Help??


in reply to Perl and Infiltrating PHP Workplaces

Perrin: I've read that PHP is comparable in speed to mod_perl, but if all you have available is CGI (as is the case on most remote hosting accounts?), then PHP is going to run significantly faster. Unless I'm missing something obvious here.

As for being faster to code, it's faster for small things to work from one file and insert a few lines of code, than it is to work with a templating system and keep the code and HTML separate. Of course, some people may want to keep them separate just on general principle - or if the people managing the content get confused when you mix in code - and in those cases Perl is definitely the better solution. But again, not if all you have available is CGI.

  • Comment on Re: Perl and Infiltrating PHP Workplaces

Replies are listed 'Best First'.
Re^2: Perl and Infiltrating PHP Workplaces
by Juerd (Abbot) on May 24, 2006 at 11:07 UTC

    Perrin: I've read that PHP is comparable in speed to mod_perl, but if all you have available is CGI (as is the case on most remote hosting accounts?), then PHP is going to run significantly faster. Unless I'm missing something obvious here.

    What you read is wrong.

    CGI is not Perl, but a protocol that allows a webserver to communicate with specially designed programs. These programs can be written in any language, including both Perl and PHP. The only requirement is that the CGI program is executable.

    CGI is slow, so both Perl and PHP offer an integrated solution, that runs within Apache. These solutions are called mod_perl and mod_php respectively.

    In general --though exceptions exist-- mod_perl is faster than mod_perl, and CGI+Perl is faster than CGI+PHP. It's incredibly silly to compare speeds of mod_php versus CGI, as the integrated solution will win from the heavy communications protocol that involves forking off a new process for each pageview.

    It's true, that if all you have are mod_php and CGI, the mod_php solution will probably run faster. But this is only relevant if you're tied to cheap bulk hosting. Businesses that hire developers usually have enough funds to configure their own server, or to have a better equipped shared hosting account. A few hours of development is much more expensive than the difference between cheap bulk hosting and your own supplier-managed dedicated server. By using a scalable, programmer-efficient language like Perl, you save more than just a few hours, if your developers are competent.

    As for being faster to code, it's faster for small things to work from one file and insert a few lines of code, than it is to work with a templating system and keep the code and HTML separate.

    It is, but maintenance will suck real soon after that. Clean code is more work, but that is an investment that will save time, and thus money, in the future. Only if your business is small and never gets new employees, you can do without code separation and documentation. But most businesses want to grow, and thus have to invest in a stable foundation for future activities. Code mixed with content is a fragile base. (And don't forget that this isn't Perl versus PHP anymore, as you can easily use content and code with Perl. It takes only a few regexes, or one of many CPAN modules, to accomplish this. And, of course, it is possible to cleanly separate code from content with PHP -- just don't expect the result to perform well.)

    Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }

Re^2: Perl and Infiltrating PHP Workplaces
by perrin (Chancellor) on May 24, 2006 at 14:30 UTC
    Perl has many templating systems which work in the same way as PHP. They don't require you to keep the HTML separate.

    Regarding ISP limitations and CGI, this person's question made it sound like the company would have their own servers and would not be subject to this problem. With FastCGI more widely available, that's another option for running Perl fast.

    Something that PHP users often don't realize is that many ISPs run PHP through CGI. They do this for security reasons. Next time you are evaluating an ISP for PHP, check to make sure they offer PHP through mod_php or FastCGI, not just through CGI.

    UPDATE: Also, make sure your ISP's PHP offering includes a code cache, because without one PHP doesn't come close to Perl's performance.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://551275]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2024-04-23 10:39 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found