It is precisely this overhead that needs to be eliminated. Time is money and if you are working with a new application on a weekly or monthly basis the scaffolding overhead comprises a great deal of that time. Not to mention that most web applications today are running to and fro from a database. This time spent fetching and storing data makes up for a significant chunk in the overall development. 2009 is a big step forward for PHP and there are tools out there that tackle this problem.

Enter ZendFramework 1.8, just recently released it represents Zend's commitment to make PHP a competitive environment for Rapid Application Development (totally RAD). There are several new tools included within this release, primarily Zend_Tool, Zend_Application, and Zend_Navigation. Zend_Tool_Project allows for the automated creation of new projects complete with a ready to go application shell. You can liken this shell to a new Hello World! project with the core structure and scaffolding setup. Rather than going into the details of everything included within the release, you can find a thorough overview within the 1.8 release notes.

This brings me to what I'm really excited about. Recently we pushed out PHP ActiveRecord for everyone! This tutorial goes over the steps necessary to build your environment. You'll be able to create new projects within the ZendFramework with PHP ActiveRecord. I believe developers should spend their time dealing with application logic and not be burdened with configuration, bootstrapping or custom SQL. For this tutorial I am using the following environment:

- Ubuntu 9.04
- PHP 5.3-RC1
- MySQL 5.4
- Apache 2.2.11
- ZendFramework 1.8 min
- php-activerecord 0.9

For the sake of keeping this tutorial short and concise, there are already several resources out there that deal with compiling PHP 5.3. I'll assume you've already setup your server with MySQL, PHP and Apache ready to go. In fact, you can use nginx if you prefer going down that route or even ZendServer CE, although I personally prefer Apache. It certainly doesn't matter what you're serving out PHP with and it will probably be dependent on what you're existing environment is using.

Installing ZendFramework 1.8 and ActiveRecord

We're going to want both libraries in our PHP include directory. First you should download the latest ZF release, 1.8.1 at the time of this post. When you have it ready to go on your server it is important to make sure your environment is working. If you installed PHP 5.3 correctly you should be able to get the following output from CLI:

# php -v
PHP 5.3.0RC1 (cli) (built: May  3 2009 15:31:21)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies
# php -i | grep include_path
include_path => .:/usr/local/php/lib => .:/usr/local/php/lib

Don't worry if your include path is elsewhere, just make a note of where it is since we'll be dumping the Zend stuff there. Now to extract and install Zend:

# tar xzfv ZendFramework-1.8.1-minimal.tar.gz
# mv ZendFramework-1.8.1-minimal/library/Zend /usr/local/php/lib/
# mv ZendFramework-1.8.1-minimal/bin/zf.* /usr/local/php/bin/
# ln -s /usr/local/php/bin/zf.sh /usr/bin/zf
# zf show version
Zend Framework Version: 1.8.1

I opted to put the zf.sh into my PHP bin directory and symlink it from my bin dir. The next step is to download the source from github and unpack it into your include path to a directory called php-activerecord. Our dependencies are there and we can move on to our first project.

Create Project

Now that everything is installed, we want to test out zf create project. The following example is a bare bones project ready for us to extend:

# zf create project /var/www/newproject
Creating project at /var/www/newproject
# ls /var/www/newproject/
application  library  public  tests

That is it, you are ready for the web. Configure your web server to start serving out pages from the location you set for your new project. The docroot path should be /var/www/newproject/public. Load up your web browser and you should see your page.

Loading up ActiveRecord

Inside your application/Bootstrap.php you might notice the code rather bare. The Zend Bootstrapper will load anything within the bootstrap function starting with _init*. To tack on ActiveRecord, we simply add the following:

class Bootstrap extends Zend_Application_Bootstrap_Bootstrap
{
    protected function _initActiveRecord()
    {
        require_once("php-activerecord/ActiveRecord.php");
        ActiveRecord\Config::initialize(function($cfg)
        {
            $cfg->set_model_directory(APPLICATION_PATH . '/models' );
            $cfg->set_connections(array(
                'development' => 'mysql://user:password@localhost/newproject'));
        });
    }
}

You will need to adjust your SQL connect strings, and at this point if you want to restructure your model directory differently you may do so. There are only two configuration points, both of which you could pass from an XML or INI config. Even though ActiveRecord is loaded, we still need to test out that everything is working. In order to do this we will need to create some test data:

CREATE DATABASE newproject;
USE newproject;
CREATE TABLE books(
    id int NOT NULL PRIMARY KEY AUTO_INCREMENT,
    name varchar(50),
    author varchar(50)
);
INSERT INTO books(id,name,author) VALUES(1,'How to be Angry','Jax');

The next step is to create a model for the books table to be used from within your application. In your model directory that you set within the configuration above, create a Book.php with the following:

class Book extends ActiveRecord\Model { }

And finally to test out that everything is working, within your IndexController.php for indexAction add the following:

public function indexAction()
{
    $this->view->book = Book::find(1);
}

And so we can actually see the output, edit your /views/scripts/index/index.phtml with the following:

Today I read <?=book->name?> by <?=book->author?> and it was terrible.

As you can see, you can pull the variable set by the action assigned to the view or you can query right from the view itself if you please. If you get the following output, everything is good to go:

Today I read How to be Angry by Jax and it was terrible.

Next Steps

Going forward, there is plenty of room to extend this setup. Unfortunately, the Zend_Tool_Project abstraction documents are still being completed but there are examples out there on how to add new commands to it. One new command I am working on is the automated creation of AR models by passing a database connect string to simplify the process even further.

I realized that I was over-thinking the problem so I did a little test to just see how much overhead Drupal is adding. I can execute ten times the number of queries natively through PHP and mysql_connect than if I were to execute those queries from within Drupal with just bootstrap included. Apache answered requests and processed these several million round trips to the database much faster. I understand that as a framework there is a lot being loaded, but a whole decimal point off when dealing with requests/sec is a huge overhead.

The better part of the last few days was spent gutting the inner workings of Drupal and removing as much of it as possible to lover overhead, reduce response time, and hopefully let us scale a little further on the hardware that we have. As it is, traffic is growing a steady 40-50% month over month for a while now and we are already dealing with several million unique visitors a month. That number is growing rapidly with no ceiling in the near future and it's unfortunate that at this point the only way to make this work is to break the upgrade path of Drupal.

Going through the code base, it's easy to see where so much of the bloat comes from. With comments like: "TODO: remove this when we require at least PHP 4.4.0" there is a lot of backwards compatibility that is required to support such a large community. I am seeing more and more Frameworks replace legacy CMS systems that provide a bare bone set of tools. The agility, performance, and maintenance of a ground up site using frameworks like Symfony or Rails leads to longer development cycles and increased costs but there is a point where you stop putting a round peg in a square hole and realize that the cost of maintenance and development down the road will far exceed the up front investment.

I'm glad Drupal has been able to take us this far and I'm very grateful for the community behind it. It's a pleasant surprise that everything is still working and hopefully we can get a few more miles out of it before we are ready to do the next iteration of the site.

This will be the first post in a multi-part series, each of the following installations will detail the technologies and implementations of the upcoming CitySquares revision. I hope to cover the entire page generation process, starting with the user's first request to the resulting dynamically generated HTML, CSS, JS, etc. Before I dive too deep into the technical aspect of things I would like to give a brief overview of what is to come.

For starters, CitySquares currently owns and operates its own servers in a co-location not far from our headquarters. This will be the first thing to go as we switch to Amazon's EC2 and S3 in conjunction with RightScale. By switching off of our own hardware we will absolve ourselves of this oft troublesome and physically limiting layer. By using RightScale's server templates and management scripts we can control the precise number of servers in operation. Coping with increased or decreased load will be handled autonomously throught the RightScale interface, no more DoS by SlashDot and more more wasted cycles during off peak hours. Our server deployment will contain a few different types, each one specially tuned and selected for its specific purpose. Without getting into too much detail here, our deployment will consist of the following:

• HA Proxy for load balancing

• Apache with PHP and XCache

• Memcached

• MySQL master/slave configuration

• File server with automated revisioning, concatenation and minimization of css, js, etc

• Tomcat with SOLR search engine

Once setup, most of the overhead associated with operating our own IT infrastructure will be removed from the equation.

Not only will our IT situation improve but our coding environment will change dramatically as we move away from Drupal's more primitive procedural style coding practice and towards Symfony's OOP style. Symfony is a PHP based MVC (Model, View Controller) framework. It is loosely based on RoR's (Ruby on Rails) best practices for codability and maintainability. We will be using it with the Doctrine ORM (Object Relational Mapping) and Smarty templating engine. These architectural and IT changes will work to promote a cleaner, more efficient and maintainable coding practice. In the end all these disruptive changes will be justified, allowing us to focus on what we do best, provide users with hyper-local search results.

]]> http://www.derivante.com/2008/07/21/a-technology-overview/feed/ 1 http://www.derivante.com/2008/07/18/turning-the-page-php-symfony-orm/ http://www.derivante.com/2008/07/18/turning-the-page-php-symfony-orm/#comments Fri, 18 Jul 2008 18:23:42 +0000 Justin Leider http://justinleider.wordpress.com/?p=3 I have come to the conclusion that I should be cataloging my work, thoughts, theories and activities for others to read and learn from my experiences as a web engineer. Let me begin by mentioning I work at a company called CitySquares and for the last year I have been working diligently on the current CitySquares site.

This has been a great year for me as I was given the opportunity to learn the inner workings of the Drupal CMS. While Drupal is a great CMS/Framework, it is inherently still a prepackaged CMS designed for things that 99% of the community needs. CitySquares unfortunately falls within that other 1%. I must say that we have accomplished quite a bit using Drupal's community modules in conjunction with our own custom written ones. However, there are plans in the works that we would like to implement but just cant within the Drupal framework.

Although all is not lost. With the current iteration running and stable and gaining traffic every week I have the opportunity to turn the page and begin work on the next phase of development. This is an exciting time and I will use this medium to convey the successes as well as the issues as development here continues.

That said, we have decided to scrap our Drupal based architecture in favor of a more extensible framework, Symfony. Symfony is a PHP based OO architecture that resembles Ruby on Rails. Not only will we gain the benefit of switching to a OO style framework but we will be using Doctrine as our ORM and Smarty as our template engine.

The idea is that this combination of technologies will help us alleviate two of the major problems we have with Drupal, essentially scalability and codability. Ive been toying with some ideas to help eliminate these two thorns in our side that I will discuss at a later time but look forward to hearing my ideas on a full stack horizontal architecture.