The Yii Framework is built for speed and the goal is to provide the best possible framework for your next large-scale web 2.0 applications. With it's superior performance, Yii still provides an easy-to-use and highly extensible feature set that is richer than most other frameworks.

If you haven't tried it, he points out the "getting started" tutorial offered on the Yii site as well as some of the performance benchmarks (including those for the next release, 1.0.1).

A disclaimer which I should have added to my last article would include that most of my pseudo benchmarks are very subjective and also way too basic. For example, our server setup is pretty comprehensive but we have to take everything into account in order to provide real benchmark. And when I write everything I mean CPU (cores), RAM, motherboard, HDD and so on. Maybe even the throughput of the network card -- if it's different.

This second post is an attempt to correct some of the sore points from the previous one. Here's a list:

• require/include(_once) and __autoload, or "Why is __autoload() 'better'?"
• Zend_Loader ERRATA
• Caching database results
• Zend_Db
• Zend Framework (what it currently lacks)

As it might be expected, there are several techniques to optimize the delivery of web pages. The Exceptional Performance guide by Yahoo is a great resource for a multitude of optimizations practices, including specifically two techniques which I will address in this article - script minifcation and concatenation.

Suggestions include reducing total request counts and minification of external libraries via the Minify tool.

The other day our servers were overwhelmed with the rising traffic and I started profiling my application through Xdebug.[...] On this project we currently run with 100,000 visitors per day on average, our peak is Sunday night where we get a ton more traffic than usually. [...] Here are a few things, that helped us. Suggestions are in no particular order and I should add that whatever is applicable for my situation, doesn't have to work for you.

His suggestions include using APC for caching, using __autoload, caching of DB queries, and some Apache tweaks to reduce what it has to load/use for each request.

REF CURSORs are common in Oracle's stored procedural language PL/SQL. They let you pass around a pointer to a set of query results. However in PHP, PDO_OCI doesn't yet allow fetching from them. [...] One workaround, when you can't rewrite the PL/SQL code to do a normal query, is to write a wrapper function that pipes the output.

He includes an example, creating an example myproc() that contains the query to select the last names of all employees in the table. This procedure is put inside of a package so it can be called directly in the SQL statement and the ref cursor can be automatically piped to output.

I have been critical of ZF in the past because the performance has pretty much been going down every release and I am not the only one seeing this, there have been a number of benchmarks that show this trend. Having contributed to ZF in the past I brought this issue up multiple times both on the mailing list and even during the meetings the past zendcons and it the general response was they where focusing on features not performance.

He points out a few things that were brought up at this year's Zend/PHP Conference & Expo including the performance focus of future releases, a push to 2.0 after PHP 5.3's release and some of the changes that can cause breaks in backwards compatibility.

Be sure to also check out Matthew Weier O'Phinney's response to the post and some of the comments Richard made.

I haven't changed great parts of the code or anything, I just benchmarked how different global include strategies affect the overall performance of my blog software written with help of the ZF. The following include strategies were tested (I've used the Zend Framework 1.6 RC2 package for all of them): Zend_Loader_Autoload (default and swapped include paths), ZF 1.6 RC2 stripped of require_onces and stripped of require_onces/no autoload and all files directly included.

He ran the tests both with and without APC enabled with a larger difference between the stats without it turned on for each of the four tests.

It was with some interest, then, that I viewed Rasmus Lerdorf's slides on the subject of performance benchmarking. I'm beginning to think there's something unexpected or unexamined in his testing methodology.

Paul compares some of his statistics (gathered from his testing) to those of Rasmus and finds a few places where things don't quite match up - specifically in the default overhead that seems to be a part of Rasmus' stats. Paul goes on to look at EC2 as a cause to the problems but ends up without much of a confirmed answer.

After one particularly frustrating day [looking at how the Zend engine works] I asked a colleague (Andy Wharmby) about the issue I was looking at. Then a miracle happened - he'd not only looked at it but had documented it (and many other things) in a set of charts.

She has linked to the charts (Open Office format) for the results of some tests her friend had already run. They're a bit out of date and some parts might be inaccurate, but they're still a good start.

Overview

The Ning Application Engineering team is a small, flat, and highly productive team of people building software that matters to millions of people in their daily lives. We use PHP and Javascript on top of the Ning Platform to deliver an extremely friendly and infinitely customizable experience to Network Creators on Ning.

Responsibilities

• Ensure that Your Own Social Network for Anything is as fast as possible. Then push to make it faster.
• Be the performance expert across all of our application development efforts - define the goals and framework for ensuring we are always getting faster as a service.
• Work closely with all members for the application development team to optimize the performance of each component and/or feature.
• Perform regular architecture and design reviews for new and existing features from a performance standpoint.
• Monitor overall site performance using internal and external tools. Develop tools as needed.
• Identify and own performance issues, design and develop code to address these issues.
• Identify performance hotspots and risks. Develop short and long term plans to address these issues before they impact growth

Qualifications

• BS/MS in Computer Science.
• Direct and extensive PHP and/or cross browser web development experience.
• Knowledge of PHP internals, Apache, and system profiling tools.
• Deep knowledge of how web pages and their elements are processed and rendered across all major browsers and their versions.
• Extensive experience with JavaScript, HTML, and CSS.
• Experience programming scalable web applications and considerably improving their performance.
• Knowledge of web services, and agile development methodologies desired.
• Experience working on websites with very high transaction volumes.
• In-depth knowledge of network programming, and HTTP protocol.
• Recent hands-on experience with some script and shell programming (e.g. Perl and Shell).
• Personality, comfort and desire to be a leader.
• Curiosity. You've created a social network on Ning. You dive into a bit more detail and are struck by the Ning Content Store and why we chose that architecture. You have ideas on how to make the site better and faster. You have lots of technical questions for us.

Please send your resume to yoonie@ning.com