It can get you up and running pretty fast and has pretty good performance for ORM. DooPhp has great php performance and a simple basic mvc structure.

However there are three situations I can think of where this kind of generated models in protected/models/ can be problematic.

1. Optimizing complex queries.
2. Extended Vertical Partitioning
3. Extended Horizontal Partitioning (Database sharding)

I had an install of multi user wordpress which has 1000′s of tables over 1000′s of databases. To be able to access this app with the DooPhp framework I also had to add in a class that allows the framework to access multiple databases on the same request.

So what did I do?

1. I replaced Doo::db class with one that was basically the same as the SQL Magic class except all of the ORM is and sql generators is removed. Function query() is rewritten to use PDO bindValues.

2. I have one class in Models which parses php ini files (one file per view). In the php ini files is the sql and bind paramaters. Depending on the blog that is being accessed the db is changed and the table prefix is also changed. This does not actually generate models but instead is a wrapper that quickly routes $variables like $_GET, $_POST into specific queries then executes them using PDO. It would not require much to extend to use PDO Fetch Class for CUD views.

This is a sample of how the db controller looks although db prefix settings are generated on the fly:

    public function index(){

	    Doo::loadModel("BaseDb", false);

            // Initiate class and load /protected/sql/wordpress.ini file

	    $db = new BaseDb('wordpress');

	    // set the db prefix, usually for wordpress this will be wp_

	    $db->prefix = 'wp_2_';
	    $db->values = $this->params; // :post_type :post_status :limit

	    $db->sql_query = 'get_posts';
	    $results = $db->query();

	    // set query to get_tags
	    $db->sql_query = 'get_tags';

	    foreach($results as $result) {

		//add each post to post array
		$id = $result['ID'];
		$posts[$id ]['posts'] = $result;

		//get tags for this post ID
		$db->values['id'] = $id ;
		$posts[$id ]['tags'] = $db->query();

	    }

	    echo '
';
	    print_r($posts);
	    echo '
';
	    //$this->renderc('index', $posts);

    }

If you are interested in more you can visit here:

Parse Ini PDO Sql

I like Parse Ini File. It has a simple syntax and parse_ini_file is reasonably fast because its written in C.

WordPress Controller

Ini File Example

It has some solid documentation and is simple to use. It has some nice helpers to get your applications started including a gui for building controllers and other tasks. It’s got other good features built for scalability.

So I didn’t do an ab test first as a benchmark because it just hits the same page everytime. I just loaded all the pages on the doophp demo blog from scratch and checked out the load times for the dynamic pages. Now I’m not comparing to other frameworks but what I can confirm is after checking the my Nginx server logs, first time page renders are around 10 to 20 times faster than bare bones install of wordpress.

The cool thing about this framework is that it’s very easy to have a rest api and that its easy to design apps where only the dynamic parts of the page are loaded. This makes it ideal for designing apps that can utilize Nginx’s SSI includes module.

With AB test.

I did a test on an old laptop with Nginx and PHP-FPM installed on Ubuntu. ab -t 30 -c 10. A test for 30′s for concurrency 10.

This test is pretty worthless in my opinion but doophp was still around 10 – 20 times faster depending on whether it was an index/archive/tag page or just a post page.

I checked out where the disk I/O was coming from with Top. Once in Top by pressing capital ‘O’ then ‘p’ let me see what was causing the minor disk I/O.

I have 1440 megabytes of Ram on this box. php-fpm max_children should be set according to the specs of your box. Just adding a large of max_children can at best use up your resources with little increase in performance and at worst bog down your server.

To fix it I changed my php.ini file. Previously I’d changed my kernel.shmmax to 256m, set my php-fpm max_children to 25. Then I had the following settings for APC (along with others) in php.ini:

apc.shm_segments = 1
apc.shm_size = 256

I changed these to:

apc.shm_segments = 25
apc.shm_size = 32

This reduced the disk I/O dramatically. That’s 25 shared memory segments each with 32 megabytes of memory.

As outlined in my other nginx image filter module post you need to implement the image at configuration time when you build nginx.

You have one nginx instance dedicated to image resizing and requests for image resizes get proxied to the nginx image serving instance from your main nginx server.

Resized images and cropped images are served like so:

Resize

http://subdomain.muinstall.com/ngimages/resize/files/2009/04/24879.jpg?w=120&h=120

Crop

http://subdomain.muinstall.com/ngimages/crop/files/2009/04/24879.jpg?w=120&h=120

You must include both w and h for width and height. If you miss either of these parameters you’ll get 415 errors.

Install Nginx Image Server:

sudo apt-get install libgd2-xpm-dev
./configure --prefix=/usr/local/nginx_images --with-http_image_filter_module
make
make install

Copy /etc/init.d/nginx /etc/init.d/nginx_images

Make changes to following lines on /etc/init.d/nginx_images.

DAEMON=/usr/local/nginx_images/sbin/$NAME
PIDFILE=/usr/local/nginx_images/logs/$NAME.pid

Here is the config for the nginx image server (/usr/local/nginx_images/conf/nginx.conf):

user  www-data;
worker_processes  1;

events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    log_format small '$body_bytes_sent $request_time $request_uri $args $status $uri';

    sendfile        on;
    keepalive_timeout  65;

    server {
    listen       81;
    server_name  localhost;
    access_log  logs/host.access.log  small;

        location / {
                    root   html;
                    index  index.html index.htm;
        }

        location /crop/ {
                set $width $arg_w;
                set $height $arg_h;
                proxy_set_header Host $http_host;
                proxy_pass http://127.0.0.1:80;
                image_filter   crop  $arg_w $arg_h;
                error_page     415   = /empty;
        }

        location /resize/ {
                set $width $arg_w;
                set $height $arg_h;
                ### if we don't set proxy header as http_host the host is read a 127.0.0.1
                proxy_set_header Host $http_host;
                proxy_pass http://127.0.0.1:80;
                image_filter   resize  $arg_w $arg_h;
                error_page     415   = /empty;
        }
        location = /empty {
            empty_gif;
        }
            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }

    }
}

Here is what you add to your main nginx mu install server conf:

    location ~* ^.+\.(jpg|jpeg|gif|png|xml|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$
    {
   	access_log  /usr/local/nginx/logs/statics.access.log small;
        root /home/mu/public_html;
	if ($request_uri ~* "/ngimages" ) {
		error_page 404 = @ngimages;
	}
	rewrite ^/resize/files(/.*)$ /wp-content/blogs.dir/$host/files$1 last;
        rewrite ^/crop/files(/.*)$ /wp-content/blogs.dir/$host/files$1 last;
	rewrite ^/files(/.*)$ /wp-content/blogs.dir/$host/files$1 last;
        break;

    }
    location @ngimages {
        access_log  /usr/local/nginx/logs/ngimages.access.log small;
        proxy_read_timeout 10;
        proxy_cache_key $host$request_uri$args;
        proxy_cache_valid  200 304 7d;
        proxy_cache_valid  301 302 1h;
        proxy_cache_valid  404 403 402 401 504 502 20m;
        proxy_cache_valid  any 1m;
        proxy_cache two;
        proxy_set_header Host $http_host;
        rewrite ^/ngimages/(.*) /$1 break;
        proxy_pass http://127.0.0.1:81;
        }

wp-config at the bottom after abs path define and before require wp-settings:

if ( !defined('ABSPATH') )

	define('ABSPATH', dirname(__FILE__) . '/');

if ( !defined('WP_CONTENT_DIR') )
	define( 'WP_CONTENT_DIR', ABSPATH . 'wp-content' );

if( !defined( "UPLOADBLOGSDIR" ) )
	define( "UPLOADBLOGSDIR", 'wp-content/blogs.dir' );

if( !defined( "UPLOADS" ) )
	define( "UPLOADS", UPLOADBLOGSDIR . "/{$_SERVER['HTTP_HOST']}/files/" );

if( !defined( "BLOGUPLOADDIR" ) )
	define( "BLOGUPLOADDIR", WP_CONTENT_DIR . "/blogs.dir/{$_SERVER['HTTP_HOST']}/files/" );

The file at /wp-content/blogs.php uses a tonne of unnecessary resources and Nginx Image Filter Module can easily save this problem.

You need to set up two instances of Nginx.  One which servers files as per normal and another instance with serves images.

The main server proxy_pass the request and args to the nginx_image server which sends them back resized.  I will have a full write up soon but here is a preliminary setting for the Nginx Image Server.

This is the basic set up. I have not included the key ingredient for the main nginx nginx.conf file. More soon.

For image server set up extra nginx with this configure:

./configure --prefix=/usr/local/nginx_images --with-http_image_filter_module
make
make install
cp /etc/init.d/nginx  /etc/init.d/nginx_images
(change any setting in the file /etc/init.d/nginx_images from "/usr/local/nginx" to "/usr/local/nginx_images" )

Extra conf for image server.

location /img/ {
set $width $arg_w;
set $height $arg_h;
proxy_pass http://127.0.0.1:80;
image_filter   resize  $arg_w $arg_h;
    error_page     415   = /empty;
}
location = /empty {
    empty_gif;
}

wp_generate_attachment_metadata