Our site and system has a lot of throughput and it make us use more instances and try to reduce the load in every part. It makes the company happy (save money) and also make the customer happy (faster load). On this article I will go over few things in terms of architecture and some code changes/strategies that could make your application faster as well.

Some of the recommendations include:

• Installing the APC/opcode caching to help save execution time
• Avoiding as many network requests as possible
• Use local file/data caching
• Using the "requestAction" inside controllers with its built-in caching

By applying a few simple modifications, and even some more complex enhancements, CakePHP can be sped up quite a bit. By the time you work your way through even half of these changes, the performance of your your CakePHP site will be comparable to many other popular PHP frameworks, with the advantage that your development speed will never falter!

There's several tips in their list - some a bit more difficult to accomplish than others, but worth the results:

• Upgrade CakePHP Versions
• Disable Debug Mode
• Disable Recursive Find Statements
• Cache Query Results
• Install Memory Based Caching
• Removing Apache and Installing Nginx
• Configure Nginx to use Memcached
• Remove MySQL and Install Percona

For more information on the CakePHP framework, see the project's main site.

Profiling is the process of measuring the execution time of each function or method call involved in servicing a single page request. The data collected from this process can reveal issues such as a particular method taking a long time to execute or being called a large number of times. Profiling a PHP script generally requires installing a PHP extension. The two more popular extensions for this purpose are Derick Rethans' Xdebug and Facebook's XHProf. This article will focus on XHProf.

He walks you through the installation of both and shows you some sample results of the profiling of a simple application and how you can compare the results across profiling runs. Additionally, if you install graphviz support, you can generate the call stack output in a visual form to make for easier consumption.

He goes through the thirteen rules to help improve your website's performance including:

• Make fewer HTTP requests
• Gzip components
• Make JS and CSS external
• Remove duplicate scripts
• Configure ETags

For more information about the YSlow extension (available for Firefox, Chrome, Opera and mobile devices), check out the project's page on Yahoo's Developer section (including ten more rules it checks).

When it comes to optimization, there are two competing viewpoints in the PHP community. Some say that optimization should only ever be an after thought and to avoid premature optimization at all costs. Others will say that this is impractical, and you should make your application fast as you write it, since then you won't have to go back and clean it up to make it faster. While I can understand the viewpoints of both sides, I am firmly in the former category.

He talks about the "90/10 Rule" of development (most of the work is done by only a small part of the code) and what that critical 10% could be made of. He also touches on the "60/40 Rule", "instinctual optimization" and the emphasis people put on benchmarks for their tool or framework of choice.

Hopefully at some point, your website is going to get a lot of traffic. Yay, you've reached your goal of getting good traffic, but it is soon followed by issues with performance and load. I like to call these the growing pains of a website. So as a web developer, I suddenly have the epiphany of "Hey, I need to scale my website!" What follows next is the biggest mistake a web developer can make: They start looking at articles on how Google scales, or maybe how Facebook manages all of their traffic. This is a mistake! To be brutally honest, you are not Google. You are not Facebook. You are not Twitter. You are a website that receives less than 0.000001% of the traffic that some of the major websites receive.

He includes a "reality check" of the setup behind a popular social site, StackExchange, with comments from their own post about their infrastructure. He talks about things included in a move to "middle-scale" like adding caching, performance tweaking, moving to a multiple server model and using replication.

People like micro-optimizations. They are easy to understand, easy to apply... and useless. But some time ago, while reviewing pull requests for Twig, I read an interesting discussion about the performance of the ternary operator in PHP (thanks to @nikic for the investigation). Do you know which [example] snippet is the fastest (of course, they do exactly the same)? The right answer is: it depends.

He notes that it's all about the data being worked with. As some of his tests show (testing code included) there does end up being a difference between using it on a small and large dataset. After investigation, it was found that the ternary operator copies (copy-on-write) the value versus an "if" that just evaluates. He also mentions the new "?" version of the ternary syntax in PHP 5.3, but notes it still suffers from the same issue.

The true path to the downloadable content can be revealed easily and is not protected, allowing users to bypass web forms and download the content directly using a browser. [...] The Solution: A Secure and Efficient PHP Download Script

This tutorial is actually an update of their previous tutorial looking at a similar subject, with a few differences. Their code provides a way to limit the files a user can download, the number of times they can download it and a script to read the file and push it to the user without them ever knowing the path.

One such limitation that I've recently seen is the performance of Zend_Config. This class underpins the mechanism by which developers provide configuration to the application, and all this config is passed around in the form of Zend_Config objects. [...] For the purposes of this article, I'm referring specifically to config INI files, using Zend_Config_Ini to parse. This is a very common format for Zend applications to use - it is familiar to developers and infrastructure support teams - and is the case where the performance issues become apparent

He talks about parsing ini files and the complications that can come with the Zend Framework method of parsing them - conversion to objects via a recursive method, merging data from different sections and the overhead toArray can cause. He shows an alternative that uses array_replace_recursive to handle the parsing and a class version that offers backwards compatibility with the Zend_Config structure. He claims to have seen a sixty percent jump in performance using these methods over the Zend Framework's defaults.

Yesterday Dan Horrigan (another PHP framework user and developer) suggested we all have a go at "Benchmark 2011". A chance for every framework developer or interested party to take their framework of choice, make a hello world and post it up online for a fair and factual survey of how many requests per second the base of the framework can handle without APC, etc. [...] This is not a new idea and it is certianly not meant to be an all encompasing comparison of framework features. The logic here is the same as testing the speed of server software such as Apache vrs Nginx.

He's included some rules to follow in creating your examples including the use of the latest release of the frameworks, no modification to the core framework files is allowed and you must create a publicly accessible repository with the example's files. If you're interested in participating, you can create your example and tweet about it with the "#benchmark2011" hashtag or just post about it in the comments.