2010 September
PHPConference Barcelona 2010
Come to the Citilab to see Ilia Alshanetsky, Fabien Potencier, Stefan Priebsch, Lorenzo Alberton, Enrico Zimuel and many more open the hood and expose the secrets of PHP and PHP related technologies that make the Internet what it is today, and that power what the Internet will be tomorrow.
The PHP Barcelona Conference 2010 will take place from the 29th to the 30th of October and is a unique opportunity to share knowledge and expertise with other developers, architects, managers, and prominent community members on the very shore of the Mediterranean sea.
Join PHPBarcelona and attend Enrico’s session, Zend Italy Consultant :
How to scale PHP applications – Enrico Zimuel – Saturday October 30th – 11h00 – 12h00
Over the last years a lot of high traffic websites have been built in PHP. One of the main problem to design a distributed PHP architecture is how to share session data between multiple servers. In this talk i will present the most popular solutions to scale a PHP application across multiple servers. I will introduce different solutions to share session data using open source solutions (nfs, databases, memcached, redis, etc). Moreover I will talk about Zend Server Cluster Manager, an enterprise-ready Web Application Server, for running and managing a HA Cluster of PHP servers.
Zend\Tool providers in ZF2 (dev1)
I’ve started playing with the development versions of ZF 2.0 and one of the first things I thought I’d do was to port Akrabat_Db_Schema_Manager. It turned out to be reasonably easy.
All I needed to do was rework my use of ZF components to use the new ZF2 ones. Whilst I was at it, I also converted it to use namespaces. I also had to reorganise the http://github.com/akrabat/Akrabat library so that I could have ZF1 and ZF2 code in it.
The DatabaseSchemaProvider
Before:
<?php class Akrabat_Tool_DatabaseSchemaProvider extends Zend_Tool_Project_Provider_Abstract { //etc
After:
<?php namespace Akrabat\Tool; class DatabaseSchemaProvider extends \Zend\Tool\Project\Provider\AbstractProvider { //etc
The filename, DatabaseSchemaProvider.php, is the same and the file lives in the Akrabat/Tool directory as before.
You can see the class now extends from \Zend\Tool\Project\Provider\AbstractProvider. This shows one of the consequences of moving to namespaces: with a one to one mapping, we would have ended up with a class called Abstract which isn’t allowed, so the classname has been changed to AbstractProvider. There are a fair few class name changes like this throughout ZF2, so expect to do a bit of file browsing
The rest of the changes that I had to make are exactly the same type namespace conversions and that was all I had to do. Maybe when the autoloader is updated, then more changes will be required and if so, I’ll no doubt write it up!
The new Akrabat\Db\Schema\Manager is available on my github account. The readme contains instructions on how to set it up with ZF2 too.
Autoloading with the Zend Framework
By adding autoloading to your application, you can make your code cleaner, save time, and even make your application run faster. The Zend Framework makes autoloading very easy, for both projects using Zend_Application or Zend’s MVC components and those that simply use Zend components to supplement their existing code.
Benefits
Autoloading is a feature of PHP that allows files to be (automatically) included at the last minute. Traditionally, to include another file you would use something like:
1 |
require_once '/path/to/somefile.php'; |
2 |
include '/path/to/includefile.php'; |
which works fine, but will break down on large scale applications with high traffic levels. require_once and include_once are both computationally expensive, meaning that you want to avoid them if you are concerned about performance (and who isn’t?), especially now that Google is factoring your site’s speed into their rankings.
Autoloading removes the need for these types of calls (and performance degradations) by handing off all loading of files to PHP itself. This is often called ‘lazy loading’…all requires and includes are done at the last possible minute, conserving resources and avoiding the expensive require_once and include_once calls.
NOTE: Autoloading is only applicable to loading classes on the fly. Files that include only function definitions or configurations cannot be autoloaded.
Getting Started
Autoloading with Zend is incredibly simple. Just place the following code into one of your application’s early running boot-up files. By simply adding this code, Zend will attempt to autoload all of your classes (assuming they follow a logical and consistent naming structure, discussed below). Of course you can replace MyLibrary with whatever name you desire.
1 |
//Must still do one require_once, to load the Autoloader class itself |
2 |
require_once 'Zend/Loader/Autoloader.php'; |
3 |
4 |
$autoloader = Zend_Loader_Autoloader::getInstance(); |
5 |
$autoloader->registerNamespace('MyLibrary_'); |
It really is as simple as that. By calling the registerNamespace() method of the Zend_Loader_Autoloader class, Zend sets up everything you need to start autoloading. The above code assumes two things:
- You have a set of PHP classes that follow a conventional naming structure…the same naming structure of the Zend Framework itself. For example, if your application uses a class called MyLibrary_Users_Guest, your file would need to be named MyLibrary/Users/Guest.php.
- Your classes are on the PHP include path.
NOTE: The above code will also setup autoloading for the Zend Framework, so you no longer need to include the files yourself. For example, immediately after the above code, without any include statements, you can call any part of the Zend Framework (and your MyLibrary classes). For example, $date = new Zend_Date();
Extra Credit
The Zend Framework, in all it’s powerful, flexible glory, has a weakness…it is somewhat slow. The blame lies in several areas, including but not limited to the number of files that go into the Framework (all the require_once‘s that must be executed for any given component) and the complexities of the code itself (which gives the Framework it’s tremendous power and flexibility).
Since applications can use bits and pieces of the Zend Framework without having autoloading setup, the Zend Framework must contain a require_once call for every dependent file. This can get slow, especially at high load levels. To increase performance, you can perform a Search and Replace in your favorite code editor and comment out all the require_once calls inside the Zend directory. The ecommerce software Magento is based on the Zend Framework and includes the Framework with all require_once‘s removed in this way.
CloudCamp @ ZendCon
CloudCamp is an unconference where early adopters of Cloud Computing technologies exchange ideas. With the rapid change occurring in the industry, we need a place where we can meet to share our experiences, challenges and solutions.
At CloudCamp, you are encouraged to share your thoughts in several open discussions, as we strive for the advancement of Cloud Computing. End users, IT professionals and vendors are all encouraged to participate.