New on the L2Admin.com site today is the first part of a series they're doing comparing three of the popular server-side scripting languages for web development - PHP, Perl and Python - and what benefits each can give.

For a very long time I have wondered if there were any real benefits between Perl, PHP or Python from a performance standpoint [...] So after much wondering I have decided to answer the question for myself once and for all. I am going to perform three tests that I think typify the use cases for all three languages, I am also going to code the same tests in C and in static HTML.

This first post shoes the results from the most basic of tests - a "hello world" that's echoed out to the page. He ran the tests with Apache's ab tool for 10,000 times and recorded the request per second, average request time and the overhead as compared to plain HTML. It's interesting to see the jump from the HTML baselines when the languages start getting involved with the stock PHP install coming in as the slowest of the group.

On the SitePoint "Server Side Coding" blog, there's this look at caching to help solve some PHP performance issues.

In the good old days when building web sites was as easy as knocking up a few HTML pages, the delivery of a web page to a browser was a simple matter of having the web server fetch a file. [...] Then dynamic web pages came along and spoiled the party by introducing two problems: a delay for processing and a check of the file's age before it's sent to the browser.

They talk about what caching can do for you, what you can do (both server and client side) to prevent caching, working with the headers sent from and back out to the browser, using output buffering, partial caching and using PEAR::Cache_Lite in your application.

Many thanks to Raphael Stolt for letting us know about his latest post, a tutorial on using the Zend Framework with Ajax to perform a server-side identification request.

He used a "@ajaxaction" marker in a previous article to implement the Ajax requests, but with other tools there could be an issue with the response. To help with this, he's worked up a handler to detect what needs to be done with the response. He applies this to create the authentication system, making it easy to include a simple ACL method into his application.

He includes code examples for the Controller to handle the detection, how to implement it, and the class to work with those "doclet" markers for the Ajax actions.

As mentioned over on Ajaxian.com, there's a new Ajax framework in town that's looking to "ease the development of rich Ajax applications, by generating the appropriate JavaScript code" - AjaxCore.

AjaxCore takes all the dirty work of JavaScript code generation and provides a solid foundation. The concept is to extend a Generic AjaxCore class and defining methods that handle the Ajax driven events and binding them to HTML objects.

It uses Prototype to work with the DOM and Ajax connections and to help you with binding the scripts to the different elements on the page. Code can be linked to certain elements and have that (server-side) code automatically executed when an element is referenced. You can find out more from the AjaxCore homepage and the Ajaxian post also includes a simple inline example to get you started.

It's official - Javascript sucks. Well, at least according to Harry Fuecks and the group from the last WebTuesday meeting.

The surprise outcome of last nights webtuesday - Javascript sucks harder than PHP. I still can't quite believe it. Maarten took the PHP corner against me in the Javascript corner, both of us shamelessly advocating each language under various headings.

1 minute max per topic-no outright lies although often bordering on truthiness. Verdicts provided by the audience, based on who could shout loudest from a choice [ranking].

Of course, Harry does comment that the comparison is a bit unfair (server versus client side), but there are alternatives for both (client-side PHP and server-side Javascript) so make a foundation for enough of a comparison. At the end of the night, though, the results of the votes were conclusive - Javascript was in worse shape than PHP, though the winner was "he one that came out hurting less".

DevShed continues their look at standalone PHP scripts (server-side scripting, not on the web) in part two, "Managing Standalone Scripts in PHP" excerpted from the book "Advanced PHP Programming" from George Schlossnagle.

Last week, we began our discussion of PHP standalone scripts. This week, we'll be talking about child processes, shared resources, signals, and writing daemons.

They jump right in, going first for a look at forking off child processes from the script using the pcntl functionality you'll need to build into PHP. Resource management is key to working with server scripts, and they show you how to close them out when you're through. Next up is a brief look at the types of signals that you can send to the child processes, and some good rules to follow for writing daemons in PHP.

From the group that brings you Chorizo! and Morcilla, the latest in PHP security tools, is a video showing how to find and correct the issues that your script might have on the server side (with the help of Morcilla).

This video shows you how Morcilla, our brand new PHP extension, lets Chorizo! have a look inside your application on the server.

We are able to hook into every PHP function and trace the payloads of Chorizo!. By default, Morcilla hooks into the whole MySQL function family, fopen, mail, include/require/include_once/require_once, preg_* and others. With a ZendEngine patch, we are able to trace unset variables and a lot more.

The video (basically a screen capture of the process) is a bit hard to read in the smaller version, so it's recommended to view the larger size if you want to see the options. It's interesting, though, to see how it picks out the errors and tells what they are and where you can go to fix them (like a file inclusion issue, as they demonstrate).