My idea is to store this information within a Service Container (we will use Symfony's DIC). For example here we can [define] our routes.yml. [...] We need to implement one Extension for the alias "routes". We only will implement the needed functions for YAML files in this example.

He includes the code for the extension ("SilexRouteExtension") that can be used to parse the "routes.yml" file to inject the custom routing into your application. This includes the pattern to match, the controller to route it to and the target method. You can also set some requirements like the request method (in this case "GET").

We sell an educational product that serves a predictable 15,000 requests per minute for 10+ hours/day, every day. Instead of Apache, we use nginx with PHP-FPM to handle this traffic. This is becoming a very popular setup for many companies with non-trivial traffic, but I have also found success with it in my small 256MB Ram VPS. For various reasons, nginx does a better job with memory and concurrent connection handling than Apache. In this post, I want to talk about some of the reasons you might want to go with this setup.

He talks about some of the efficiency gains that memcache and nginx can give you pretty easily and some of the common uses for nginx, including using it as a reverse proxy. He talks some about Apache's typical request handling and shows the difference between that and how nginx does its "never block, finish fast" handling. He fits in the other pieces - PHP-FPM, memcached and APC - showing how each of them offers their own types of performance gains for different areas of the application.

The power of PHP and an RDBMS is the ability to nail the major features of an application with cheaply paid developers in a record amount of time. Unfortunately, the default runtime environment used by PHP is simply an unscalable mess. [...] The truth is that if you have enough servers and enough database servers, you don't have contention. [...] As it turns out, there's a modern solution to the problem: the cloud plus NoSQL. Cloud infrastructure gives us the ability to spin up enough servers, and a NoSQL database enables us to shard our data effectively.

They talk some about why they think PHP's runtine environment is "a dog" based on the non-native pooling of database connections and the lack of a thread-safe environment.

The bottom line: PHP applications are a load on the database due to the constraints of the concurrency model.

He points to the cloud architecture and NoSQL databases as solutions to the scalability problem, providing more scalable resources and flexible data sources.

This is the final article in a three part series focused on setting up EC2 as a sandbox for application developers. I assume you have an AWS account with Amazon; if you don't, please read Part 1 to learn how easy it is to sign up. I also assume you have configured your development environment and installed an AMI; if you haven't, please read Part 2. In this installment, we'll learn how to install Apache, MySQL and PHP in our running AMI, and then clone the AMI to make our own.

Included in the post are all the commands you'll need to get the packages installed for PHP, MySQL, Apache 2, PEAR and the PHP command line binary. With all of that installed, they show you how to create an AMI (Amazon Machine Image) to make it easier to scale in the future.

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.

One of the key ideas behind cloud computing is the concept of scaling.Talking to customers and cloud enthusiasts, many people seem to be unaware about the fact that there is great opportunity in scaling, even for small applications.

Using the SDK, he shows how to create the command-line tool buy craeting a management client and setting up the command line parameters to give to the setInstanceCountBySlot() method. This gives you the ability to spawn off as many new "slots" (instances) as you might need quickly and easily.

A typical PHP application and most of the frameworks uses "The Loop"� method to code the website. Whenever request comes to website, It's typically sent to index page to handle every parameters. [...] We can use xcache variables to store entire web page and serve it from RAM.

They include some basic benchmarks showing the impact that caching an have on a site as well as code that you can use to integrate their xcache library into your site. The library uses the XCache functionality to store the rendered output of the page for a default of three hours time.

Welcome to the ZendCon 2009 edition of the ZendCon Sessions. The ZendCon Sessions are live recordings of sessions that have been given at previous Zend Conferences. Combined with the slides, they can be the next best thing to having attended the conference itself. [...] This episode of The ZendCon Sessions was recorded live at ZendCon 2009 in San Jose, CA and features Sam Hennessey giving his talk: "PHP - Faster And Cheaper. Scale Vertically with IBM i"

There's three ways to catch this latest episode - you can either listen via the in-page player, download the mp3 directly or subscribe to the ZendCon Sessions feed and get the latest episodes automatically. Be sure to check out the slides too!

If you're from the LAMP world, the concept of vertically scaling with a system like the i5 (IBM Power Systems) will be a complete revelation. If you follow the vertical scaling methodology, when it comes time to design how your application will scale, there is nothing for you to do.

With the i5 series all of the software runs locally and can be optimized for the best performance ("reduced complexity"). Virtual machines on the same physical machine make it quick and easy to create separate environments (like QA or staging). The system does a lot of the common maintenance tasks itself and could require less attention from the IT admins. You can find out more information about these machines from the IBM website.

The intuitive will note that many if not most of these suggestions are performance enhancements, not scaling techniques. Why then are they in an series about scaling? Scaling is about more than just adding hardware. It's also about making sure your system runs better. You can add lots and lots of hardware but you will someday be unable to compensate for bad queries and poor optimization.

Some of his suggestions include taking care of any sort of errors or notices (anything that could slow the script down by writing to a log), defining virtual hosts instead of making excessive use of .htaccess files and installing caching software to maximize code and information reuse.