I love the fact that it's all just self-contained. That the language includes so many helpful functions in the box. [...] PHP scales down like no other package for the web and it deserves more credit for tackling that scope.

and to that, Matthew comments:

It's nice to see leaders of projects like Rails having this same attitude. It's a breath of fresh air in the competitive market of web development frameworks.

Welcome to The ZendCon Sessions. This episode of The ZendCon Sessions was recorded live at ZendCon 2007 in Burlingame, CA. We hope you enjoy today's session as we listen to Eli White present "High Performance PHP & MySQL Scaling Techniques".

The usual three methods are all there for enjoying this new episode: grab the mp3 directly, listen using the player on the page or you can get this and other great episodes by subscribing to their podcast feed.

I thought it might be interesting to write an article about the performance-enhancing tips you probably don't want to hear about - that is, those that are most likely to produce measurable (and durable) results but do require some effort on your part.

His list consists of:

• You Don't Need To Plan Ahead In Order To Have A Plan
• Combat Database Abuse
• Do You Really Need A Database Anyway?
• Scale Horizontally
• Refactor To Scale Vertically

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".

PHP continues to enjoy phenomenal growth becoming the de-facto standard for enterprise Web applications. With the introduction of PHP 5, PHP has reached new levels of support for Web Services, XML and Service Oriented Architectures (SOA) meeting the robust demands of the enterprise environment. Learn how you can achieve scalability, performance, availability and reliability for your enterprise-class PHP applications with advanced PHP solutions from Zend Technologies.

In the webcast, Zeev talks about integrating web services, tracking and improving the response times in your application, scaling your applications, and troubleshooting applications down to the exact line of code.

In "The J2EE guy still doesn't get PHP", Harry Fuecks suggests that PHP really needs [someone] to get together and write a detailed paper on how it works and why PHP scales so we can all live happily ever after.

I could not agree more.

Sebastian even notes that just recently, such a document would have come in very handy in a discussion. Unfortunately, he hasn't had the experience needed to make such a paper himself, so he's asking the community to help on the project and give suggestions/comments/offers of help in the comments of this blog posting.

The International PHP Magazine conducted a poll over the week, asking for your opinion on 'The misconceptions surrounding PHP'. The options provided were:

• Java/ASP/Ruby/Python/Perl/C is better, and faster than PHP
• PHP does not scale well
• PHP has to write/read everything from a database
• PHP does not support shared memory
• PHP is not a compiled language
• PHP can't run for days

The results from the poll showed unanimously that the impression that Java/ASP/Ruby/Python/Perl/C are better and faster than PHP topped the charts. Coming in close are two options - that PHP doesn't scale well and that PHP isn't a compiled language (surprising).

Check out their latest poll for the week asking what the most common security mistake is.

Some of the reasons they give include:

• Many PHP-modules are not thread safe
• Non-standard date format characters
• No Unicode

Now not everyone is a programmer or a system administrator-"normal human beings" rank these highly because they relate directly to the two most pressing problems they're facing: they want a site which is visually attractive and, with limited technical expertise, installation can be a significant hurdle to overcome.

But when it comes to security or maintenance, those requirements rank pretty low down. So here's some different things to think about, following on from this talk (PDF) on page 19, which I'd argue rank much higher when evaluating a project you plan to use (further suggestions appreciated).

The points he mentions include:

• What's the security record like?
• What's the code like?
• Who's using it?