Introduction to the “Deal of the Day”–A PHP sample scaling application

Author: Ben Lobaugh <>

Date: Tuesday, May 24, 2011, 5:33:51 PM

Tags: Scenario, Scaling

Table of Contents

Note:This article pertains to the CodePlex SDK initially released late 2009. The Windows Azure team has since then released a newer version of the Azure SDK for PHP on Github. Please refer to the Windows Azure PHP Developer Center for documentation on this more recent version of the SDK.

Please stay tuned and come back here regularly as we are working on refreshing the tutorials to deliver up to date and useful content for our PHP developers.


This document contains a detailed description of the Deal of the Day (DotD) Windows Azure PHP demonstration application.

Description of DotD

Deal of the Day is a sample application written in PHP to demonstrate how to utilize Windows Azure's capabilities with PHP. In particular, DotD show how to take advantage to Windows Azure's scalability features.

Although we consider DotD being a sample, it is a fully functional application and we've decided to deploy a live version on Windows Azure to let you test it for real and give the chance to win a fun prize!

As a sample application, DotD did not undergo extensive testing, nor does the code include all the required error catching, security verifications and so on, that an application designed for production would require. So, do expect glitches and application break down.

As you can see if you look under the hood the code is very simple, designed to let you learn the available option to design scalable applications with Windows Azure.

DotD opens its architecture for visiting developers to inspect to see the inner workings of PHP on Windows Azure. Alongside DotD a series of articles detailing how to use the scaling capabilities found in DotD have been written.

To give you an opportunity to see the sample application working, we've decided to deploy a live version on Windows Azure to let you test it for real and give the chance to win actual fun prizes till June 10th! (and sorry for our friends outside of USA, but prizes can be shipped only to a US address)

Wanna play? Just go this way:
Looking for the code, just get it on GitHub here:


DotD is comprised of several pieces which fit together to create the overall experience (See diagram below).

  • Storage - responsible for containing all business data (product information & images, comments) and monitoring data (diagnostic information). All data is stored in Windows Azure Tables, Queues, and Blobs..
  • Web Roles - Point of interaction of the application with visitors. Number of active Web Roles varies depending on the load. They are all the same, running the core of the applications logic, producing the user interface (HTML) and handling user inputs. All Web Roles share the storage elements described above.
  • Worker Roles - Worker roles sit in the background processing events, managing data, and provide load balancing for scale out. The diagram shows two Worker Roles, one for managing the applications "scalability" (adding/removing Web roles) and one for asynchronously processing some of the applications tasks in the background (another way to achieve scalability)
  • Content Delivery Network (CDN) - Global content distribution that provides fast content delivery based on visitor location.

; image

Each of these parts is essential to the performance and scalability of DotD and will be discussed in more detail in later sections (Except the visitors!), but for now let's take a quick look at why each piece was chosen for the architecture.

Windows Azure Storage

The Windows Azure platform provides several services to developers, one of which is storage. Often traditional webservers will have their own storage; however Windows Azure has decoupled the storage feature and instead created an entirely separate storage service. This provides several benefits:

  • Storage is not tied to the availability of any role
  • Single point of interaction with your application
  • Storage can be partitioned and automatically scaled by Windows Azure maintaining maximum performance and availability
  • Files stored in Blob storage can be served directly through the CDN for high speed, location based access
  • Queues can be used to dramatically increase the scalability of an application
  • Tables are an easy efficient way to store data without the need for knowledge of a complex SQL language

Read more about Windows Azure Storage Services

Web Roles

DotD interacts with the outside would through a web user interface (UI). A web role is a special role that contains an installation of IIS that allows visitors to interact with application logic and data.

A web role is a role that is customized for web application programming as supported by IIS 7. The benefit of using this type of role is that the IIS setup is done for you. This role is best used for providing a web based frontend for your hosted service. It is not suited for long running processes.

(more on MSDN:

In DotD web roles do very little work other than fetching and displaying data, most of the processing is done by the worker role. The following is a brief description of how the site functions

  • Check to see if game is running
    • If game is running check to see if there is a prize available
      • If there is, display the prize
        • Fetch all comments related to the current prize
        • Display a form to enter a new comment
      • If a new comment has been submitted it is placed in a work queue for processing by the worker role
  • If the game is not running display a "paused" page
  • If visitor played, determine if a prize is awarded
    • Prizes may be redeemed with a redemption code. A limited number of redemption codes are available to visitors based on predetermined randomly generated times of availability.
    • Check captcha
      • o If it does not match silently redirect to the home page
    • Check to see if a code is available
      • If a code is available show the code along with redemption instructions
      • If a code is not available display a consolation message

Worker Roles

Worker roles are analogous to running system services, with the exception that worker role is a separate server instance. Worker roles can be used to perform any type of transaction. In the case of DotD, workers are used to check for work items from the user (such as submitting a comment) and provide load balancing. This was done to remove as much processing as possible from the web role in order to speed up page load times.

As read on MSDN "A worker role is a role that is useful for generalized development, and may perform background processing for a web role. When you have a need for a background process that performs long running or intermittent tasks, you should use this role." (more details on MSDN

DotD worker roles perform two distinct actions: processing application work items, and managing scalability. We are describing two worker roles from a logical point of view. But for simplicity the initial implementation of the DotD uses only one worker role, which combines the two types of actions.

Processing application Work Items

DotD uses a work items queue to allow behind the scenes processing of actions generated from the web role. When a user performs an action, such as leaving a comment, the comment is placed on the work item queue. Later when the worker scans the queue it will see the new comment and begin processing it. Windows Azure Queues are highly available which means the web role will always have quick access to add an item to the queue for later processing. During processing by the worker the comment can be checked against spam filters, scrubbed of bad language, or anything else imaginable with a simple string. The comment is then dumped into a table which the web role reads and will be displayed the next time the page is refreshed. Adding comments is not the only thing a queue can be used for. DotD understands several different work actions the web role generates.


In a following section titled "Building to scale" the scaling idea behind the work items queue will be explained.

Managing Scale

The Windows Azure platform enables applications to scale on demand as their traffic and work load increases. Windows Azure does not scale automatically, you have to decide when it does. Due to the widely varying nature of applications there is no absolute way to determine when to scale. Instead the Windows Azure platform provides some simple methods for developers to make their application aware of when and how to scale.

DotD underwent some performance stress tests to help us determine where the points are that require scale out. It was determined that DotD does not put much of a strain on CPU resources even when traffic is in the thousands of visitors. Instead we found that before the CPU became an issue we would run out of available sockets for visitors to connect to. It was decided that DotD needed to scale out based on the number of connections over a given period of time.

All applications will vary in requirements of when to scale out, however the same basic flow of logic will work across most scenarios. The following diagram shows a high level overview of the performance monitoring process.


In the above diagram there are 3 primary pieces

  • Performance Monitor
    • This will be detailed further below.
  • Web Roles
    • Windows Azure provides the ability to automatically collect and store performance metrics without your application needing to know how to hook into the underlying operating system itself. When you deploy your application you specify which metrics you want to track and how often. At the interval specified all newly collected performance metrics are save to Windows Azure table storage.
  • Performance Metrics Storage Table
    • Windows Azure provides a storage mechanism for performance metrics in the WADPerformanceCountersTable. Your application can then use the data in this table to perform analysis of your application's load.

Take a look at the following diagram detailing the flow of DotD's "Scale Manager"

Diagram of Scale Manager



This diagram is a rather simple high level overview of the Scale Manager. Let's see the high level descriptions, and relate it in terms of the DotD sample. Keep in mind that the current DotD scaling triggers are simplistic triggers. A real-world application will probably not only look at the current numbers but will also implement some prediction algorithm based on past resource usage and expected future needs.

Performance Monitoring Worker Role Loop

The Scale Manager sits inside of an infinite loop constantly checking load conditions of the application.

Check Metrics in Performance Table

Performance metrics stored in the Windows Azure storage table are retrieved here and any logic that needs to be done to calculate when to scale in or out is calculated.

In DotD the number of IPv4 connections is retrieved and a simple calculation takes place to determine if the number of connections is above the threshold. If it is Resource Usage is considered high. When to remove a running instance it a bit trickier. DotD uses a very simple scaling method based on number of connections. If the number of connections drops below 20 and the lowest acceptable amount of running instances is not yet met Resource Usage will be considered low.

Resource Usage

The last section determined whether resource usage was low or high, in this section the data provided from the last tells the application whether it needs to add a new instance, remove an instance, or do nothing and check again later.

In DotD the acceptable upper and lower number of connections have been used with the current number of connections to determine if the system should scale. It is important to take note here that you need to also specify the maximum and minimum number of instances you are willing to run. If you do not specify a maximum a malicious user could come along and launch a denial of service attack. This attach would cause your load balancer to continually spin up new web role instances and could result in millions of dollars in operating costs. On the other side of the spectrum, if you do not specify a lower limit and the metric you use to scale is low enough to remove a role you could wind up with no running roles at all! Here is the process DotD uses to ensure it will never spend millions of dollars during a denial of service attack, but will still be available when no users are using the application.

  • If the number of connections is above X AND number of running roles is less than Y
    • Add a new instance
  • Else if the number of connections is lower than Z and running roles greater than T
    • Remove a running instance

Building to Scale

A brief overview of the architecture used in DotD will be presented here. Designing scalable applications is a topic that has been widely documented so this article will not go into great depth on the various design patterns and when to use them. If you want to learn more about designing for scale see the links in the Additional Information section.

Minimize writes in the Web Role

To begin with it was determined that DotD should be built in such a way as to minimize the number of writes. This was accomplished to such an extent that there is no place in the application that writes directly to a table, this even includes the entire administration section. DotD only reads from tables. Page output is cached using the IIS output caching mechanism and a CDN is used on images to speed up read times.

No data processing in the Web Role

In order to decrease page load time and free up resources to respond more efficiently to visitors, no data is processed at all in the web role. Instead any data that needs to be processed is placed on a queue for the worker role to come along at a later time and process.

Data is processed in the background with a Worker Role

All data processing takes place in the worker role. This frees up the web role to focus on providing content to the user. Examples of what the worker does in DotD include:

  • Managing comments
  • Managing products
  • Maintaining the status of the application
  • Monitoring and balancing load

Utilize Queues for communication

Queues are extensively used for inter-application communication. Any web role can request an action by submitting a work item to the work queue which is then picked up by a worker and processed. Due to the nature of Windows Azure queues multiple workers can utilize the same queue for work related messages. Windows Azure queues allow the worker to hide the queue work item it is currently processing and remove it from the queue after completion. This is a great feature, that when utilized properly, will allow any number of workers to process items from a single queue and if one of the workers (or all of them) fail no work items will be lost as Windows Azure will return them to the queue after a specified period of time. Utilizing this method also allows the number of workers to be increased as the work load increases without fear of data corruption or loss.

Want to try it yourself?

To give you an opportunity to see the sample application working, we've decided to deploy a live version on Windows Azure to let you test it for real and give the chance to win actual fun prizes till June 10th! (and sorry for our friends outside of USA, but prizes can be shipped only to a US address)

Wanna play? Just go this way:
Looking for the code, just get it on GitHub here:

Additional Information

Scaling PHP on Windows Azure articles

The following is a list of articles that were compiled as useful resources during the development of DotD

Windows Azure

Introducing Windows Azure

Windows Azure for PHP


Designing scalable applications

Useful Blogs


blog comments powered by Disqus

Related Content

No related content was found