The campaign launched in November 2009 with tandem efforts online and on television. The television ad campaign was driven by images from the repoweramerica.org/wall.
In the weeks prior to launch, thousands of videos, photos and comments had been gathered by field teams in all states. The video footage and images were then uploaded by volunteers using the Admin Panel developed by SignalFive.
The complexity of the project — both tech and non-tech — was non-trivial. As a result, a number of players were involved, and various aspects of the project were assigned to teams, playing to the team's core strength(s). SignalFive's mandates were:
Based on the client's projections of traffic and growth, SignalFive drew up a fairly detailed spreadsheet that laid out the initial and ongoing monthly costs of running the Wall, going forward 12-18 months. The client approved the estimates, and development of the Wall project was given the green light.
The Wall was architected to use the 'cloud'. Videos are hosted on YouTube, and images are served from Amazon S3. Scalable 'cloud servers' were purchased from a leading-edge hosting company for the Wall application back-end and Admin Panel.
One of the challenges was to develop a system that allowed Flash to access the Postgres database. This was achieved using Flash remoting which was integrated into the PHP framework used to develop the site, CodeIgniter.
Stress-testing the application back-end was imperative because The Wall was expected to see high volumes of traffic. SignalFive performed a variety of load tests, from the Postgres database up the stack.
As a result of this rigorous testing, launch day was smooth sailing — 95,000 page views, handled without breaking a sweat or missing a beat.
While this stress-testing was valuable, and optimizations were made based on them, none of these techniques truly simulated real-world use. Typically, a testing environment such as Selenium IDE might be used. But since the UI of the wall was built in Flash, things got tricky.
We researched various solutions, and after investigating options such Silk Performer, we decided to use a new web application testing service called BrowserMob.
BrowserMob's team helped us craft some tests which we ran on the dev and production servers. The information was invaluable — based on the test results, we decided to upgrade the production server, and doubled its memory.