The libpcap file format (full name) is the main capture format used in TcpDump/WinDump, Wireshark/TShark, snort, and many other networking tools. If you are not familiar with any of the above names, those programs are packet analysers (or network sniffers).

The format is well document on the Wireshark website. It consists of 3 different data structures:

• global header
• packet header
• packet data

Packet data is an array of chars (in PHP it’s a string) and doesn’t have a defined size. It’s encapsulated by a packet header which defines its length.
A very simple (and useless) parser would have to find the first packet header, figure out length of the packet data and move to another packet header (which lays immediately after data section).

Before we get to the first packet header we need to read the global header. It begins at the first byte and holds some basic information about the file.

The global header structure is defined as follows:

typedef struct pcap_hdr_s {
        guint32 magic_number;   /* magic number */
        guint16 version_major;  /* major version number */
        guint16 version_minor;  /* minor version number */
        gint32  thiszone;       /* GMT to local correction */
        guint32 sigfigs;        /* accuracy of timestamps */
        guint32 snaplen;        /* max length of captured packets, in octets */
        guint32 network;        /* data link type */
} pcap_hdr_t; 

If you are not familiar with C, please allow me to explain what the above notation means. The simples way to think about a C structure is to imagine a PHP class with public attributes and no methods. A PHP translation can look this:

class pcap_hdr_t {
     public $magic_number; /* magic number */
     public $version_major; /* major version number */
     public $version_minor; /* minor version number */
     public $thiszone;  /* GMT to local correction */
     public $sigfigs; /* accuracy of timestamps */
     public $snaplen; /* max length of captured packets, in octets */
     public $network;  /* data link type */
}

The biggest difference is that in PHP our attributes can hold any kind of data while in C they have strictly defined type and length.

• guint32 – Unsigned Integer 4 bytes long (32 bits)
• guint16 – Unsigned integer 2 bytes long (16bits)
• gint32 – Integer 4 bytes long (32 bits)

Based on this information we can be sure that:

• the global header has exactly 24 bytes
• the first 4 bytes are the “magic_number” and should be interpreted as an unsigned integer
• following 2 bytes are the “version_major” and should be interpreted as an unsigned integer
• and so on… I’m sure you can recognise the pattern

Lets create an example pcap file on which we are going to experiment. The easiest way would be running tcpdump:

$ tcpdump -i eth0 -w example.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

(make sure you specify a network interface “-i eth0”, tcpdump can sniff on all interfaces but the output file will be saved in PCAP-NG instead of PCAP)

Generate some network traffic by visiting any website or pinging google.com, and than switch back to the terminal, and press CTRL+C.

118 packets captured
118 packets received by filter
0 packets dropped by kernel

Run `ls` to make sure there is some data in the file.

$ ls -la
total 56
drwxr-xr-x   3 lukasz  staff    102  9 Mar 01:39 .
drwxr-xr-x  62 lukasz  staff   2108  9 Mar 01:38 ..
-rw-r--r--   1 lukasz  staff  25689  9 Mar 01:39 example.pcap 

Now lets open the file in PHP and read the first 24 bytes of data.

<?php

$fh = fopen( 'example.pcap', 'rb');

if( ! $fh ) {
     throw new Exception( "Can't opend the PCAP file" );
}

$buffer = fread( $fh, 24 );

fclose( $fh ); 

Please notice the ‘b’ flag passed to the fopen() function. It forces binary mode and prevents PHP from being clever about the data.

Now we have a raw data in the buffer and we need to translate it to something what makes sense. In C one could simply cast the buffer on a desired structure (although it’s a discourage practice because it makes the code less portable). In PHP (and PERL from which the function was borrowed) you can use unpack().

Unpack takes a binary string and translates it to an array of values. To start simple lets read only the first 4 bytes which represent the magic_number.

<?php

/* ... */

$buffer = unpack( "Nmagic_number", fread( $fh, 24 ) );
print_r( $buffer ); 

The function should return something like this:

Array
(
    [magic_number] => 3569595041
) 

You probably noticed the strange “N” character before “magic_number” passed to the unpack(). It tells the function how to parse binary string. “N” stands for “unsigned long (always 32 bit, bigendian byte order)“. You can find all codes under pack() documentation.

If you want to unpack more than one value you have to use “/” character as a separator. To read the full header you can do:

<?php

$buffer = unpack( "Nmagic_number/vversion_major/vversion_minor/lthiszone/Vsigfigs/Vsnaplen/Vnetwork", fread( $fh, 24 ) );
print_r( $buffer );

That will return all header’s values.

Array
(
    [magic_number] => 3569595041
    [version_major] => 2
    [version_minor] => 4
    [thiszone] => 0
    [sigfigs] => 0
    [snaplen] => 65535
    [network] => 1
)

You might have noticed that there are 3 different types for a 32 bit long:

• machine byte order
• big endian byte order
• little endian byte order

There are two ways of storing a number which is longer than a byte. For example, number 2864434397 can encoded as: 0xAA 0xBB 0xCC 0xDD (Big-endian) or 0xDD 0xCC 0xBB 0xAA (Little-endian). Different platforms might prefer a different order. If you want to stick to your default settings you can use the “machine byte order” which is relative.

So why did I decide to use Little-endian for all values following the magic number?

The magic number in my PCAP is 3569595041. That’s 0xd4c3b2a1 in hex. PCAP documentation states that:

The writing application writes 0xa1b2c3d4 with it’s native byte ordering format into this field. The reading application will read either 0xa1b2c3d4 (identical) or 0xd4c3b2a1 (swapped). If the reading application reads the swapped 0xd4c3b2a1 value, it knows that all the following fields will have to be swapped too.

A good parser should handle both cases but for the sake of simplicity I will ignore the other possibility.

At this moment you should have a script which can read and understand the first 24 bytes of a PCAP file. The next step is to read the first packet header.

typedef struct pcaprec_hdr_s {
        guint32 ts_sec;         /* timestamp seconds */
        guint32 ts_usec;        /* timestamp microseconds */
        guint32 incl_len;       /* number of octets of packet saved in file */
        guint32 orig_len;       /* actual length of packet */
} pcaprec_hdr_t;

This structure is simpler and is always 16 bytes long. Now we have all information we need to finish the parser.

<?php

$fh = fopen( 'example.pcap', 'rb');

if( ! $fh ) {
     throw new Exception( "Can't opend the PCAP file" );
}

/* Reading global header */

$buffer = unpack( "Nmagic_number/vversion_major/vversion_minor/lthiszone/Vsigfigs/Vsnaplen/Vnetwork", fread( $fh, 24 ) );

printf( "Magic number: 0x%s, Version: %d.%d, Snaplen: %dn",
          dechex( $buffer['magic_number']),
          $buffer['version_major'],
          $buffer['version_minor'],
          $buffer['snaplen'] );

/* Reading packets */

$frame = 1;
while( ( $data = fread( $fh, 16 ) ) ) {

     /* Read packet header */
     $buffer = unpack( "Vts_sec/Vts_usec/Vincl_len/Vorig_len", $data );

     /* Read packet raw data */
     $packetData = fread( $fh, $buffer['incl_len'] );

     printf( "Frame: %d, Packetlen: %d, Captured: %dn",
               $frame,
               $buffer['orig_len'],
               $buffer['incl_len'] );
    
     $frame++;
}

fclose( $fh );

Processing PCAP is very straight forward. You have to read 16 bytes of a packet header and get “incl_len” to find out where the next packet header starts.

Although the parser doesn’t do much this example should give you a good understanding of how to deal with binary data in PHP. If you would like to push it further and find out an IP address, or TCP payload open the PCAP file in Wireshark and try to figure it out. If you need some extra help have a look at this great article about programming with libpcap. You will find there all the structures you need (sniff_ethernet, sniff_ip and sniff_tcp) with a solid explanation.

As you can see PHP is capable of doing more than generating a dynamic HTML code. It’s obviously not so as fast as C but there are many occasions when that’s not a big problem.

My liberation came from Nathan Hurst (thank you) and his priceless post – Visual Guide to NoSQL Systems. The CAP Triangle (Consistency, Availability and Partition Tolerance) narrowed down my options to “only” 8 systems (AP). I tossed an eight sided coin and chose Apache CouchDB.

Three months later I can say I’m still happy with my choice. CouchDB is simple (only 18,000 lines of code) yet powerful database. It talks JSON though the HTTP protocol. You don’t need any special tools or libraries to use it. In fact, you don’t even need a backend to create a web application because it’s capable of hosting static files.

If you’re also looking for a scalable and fast document store, or you just simply want to try a NoSQL have a look at CouchDB. It’s very easy to learn and I believe you will find it useful.

To install CouchDB on Linux use a package manager of your choice, for example:

$ sudo apt-get install couchdb

or if you are Mac/Windows user get the CouchDB binary and run it.

Once the database is running you can start playing with it though a web interface called Futon. To access it visit http://127.0.0.1:5984/_utils/.

CouchDB provides REST API and you can perform all operations with CURL. The API is well documented so I won’t discuss it. CouchDB manual is distributed with the database and you can access it locally at http://127.0.0.1:5984/_utils/docs/.

There are few PHP libraries for CouchDB although I wasn’t happy with them, and started developing my own. You can find it on GitHub if you like, but I recommend to install it with the composer.

$ mkdir couchdb-test
$ cd couchdb-test
$ curl -sS https://getcomposer.org/installer | php 
$ vim composer.json

{
    "require": {
        "lukaszkujawa/couch-php": "dev-master"
    }
} 

$ php composer.phar install

Now lets create some PHP code.

 'product-00001',
     'schema' => 'product',
     'name' => 'Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long',
     'type' => 'book',
     'reviews' => array(
          array(
               'stars' => 5,
               'title' => 'Outstanding book',
               'text' => 'One of the best books I've ever read. David Rock collects together a bunch of neuroscience(..)'
          ),

          array(
               'stars' => 3,
               'title' => 'Tough to Get Your Brain Round 'Your Brain'',
               'text' => 'I had a difficult time getting into and through this book(..)'

          ),
      )
));

$doc->insert(); 

When you run the script for the first time it will as expected populate a new document in your database.

An interesting thing will happen when you run the script again.

PHP Fatal error:  Uncaught exception 'CouchPHPClientException' with message 'conflict' 

You can’t insert the same document twice. If you want to amend a document you need to assure CouchDB that you have the latest version of it. You do it by setting a revision property “_rev” which is automatically added to a document on insert and update (see the screenshot above).

To fix it you can first get the product-00001, read _rev value and add pass it in the Document constructor.

 'product-00001',
     'schema' => 'product',
     'name' => 'Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long',
     'type' => 'book',
     'reviews' => array(
          array(
               'stars' => 5,
               'title' => 'Outstanding book',
               'text' => 'One of the best books I've ever read. David Rock collects together a bunch of neuroscience(..)'
          ),

          array(
               'stars' => 3,
               'title' => 'Tough to Get Your Brain Round 'Your Brain'',
               'text' => 'I had a difficult time getting into and through this book(..)'

          ),
      )
);

$doc = CouchPHPDocument::getById('product-00001');

if( $doc ) {
     $fields['_rev'] = $doc->_rev;
}

$doc  = new CouchPHPDocument($fields);

$doc->insert(); 

If you don’t worry about concurrency you can use “insertOverwrite” method, and the library will handle getting the latest “_rev” for you.

 'product-00001',
     'schema' => 'product',
     'name' => 'Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long',
     'type' => 'book',
     'reviews' => array(
          array(
               'stars' => 5,
               'title' => 'Outstanding book',
               'text' => 'One of the best books I've ever read. David Rock collects together a bunch of neuroscience(..)'
          ),

          array(
               'stars' => 3,
               'title' => 'Tough to Get Your Brain Round 'Your Brain'',
               'text' => 'I had a difficult time getting into and through this book(..)'

          ),
      )
));

$doc->insertOverwrite(); 

Look for the moment at the document fields. One of the properties is called “schema”. It’s an arbitrary label which defines document type. In our simple example we have only one document type but in real live you could have some additional types like: basket or order. CouchDB database doesn’t have tables as such but you can query for documents with certain properties.

To select documents of a specific kind you need to create a view. View is a JavaScript function which is stored in so called “design document”. Design documents are special type of CouchDB document and are always prefixed with “_design/“. Futon doesn’t provide a dedicated interface for creating design documents but there is a special section for creating views (which are part of a design document).

If you navigate to the test database page (http://127.0.0.1:5984/_utils/database.html?test) you will see “View: All Document” drop down in the top right hand side.

Click on the drop down and select “Temporary view…”. You will get redirected to a special page where you can design a view.

The default map function doesn’t have any conditions and will always return all documents.

function(doc) {
  emit(null, doc);
} 

Click “Run” button to see how it works.

Lets create a view which will return only product documents.

function(doc) {
  if( doc.schema && doc.schema == 'product' ) {
    emit(null, doc);
  }
} 

That will do the trick but we can push it further. The first argument of the emit function is null. You can set it to product type which will allow some more advance search.

function(doc) {
  if( doc.schema && doc.schema == 'product' ) {
    emit(doc.type, doc);
  }
} 

Click “Save As…” to save the view. First you need to specify which design document will hold the view – name it “products”. Second input is the view name – call it “all”.

Once the view is saved access it directly from your web browser http://127.0.0.1:5984/test/_design/products/_view/all. As expected the view will return our one and only product.

Now let’s imagine you want to see products which are books. The view emits doc type as a key so we can do it with two parameters “startkey” and “endkey”.

http://127.0.0.1:5984/test/_design/products/_view/all?startkey=”book”&endkey=”book”

To find all querying options look into the documentation.

Key emitted by the view doesn’t have to be flat. You can emit list of values, for example:

emit([doc.type,doc.category], doc);

Getting all books for this configuration would look like this:

startkey=["book"]&endkey=["book",{}]

It’s important to know that CouchDB creates an index for every view. It makes search faster but it cost space on disk. Another interesting fact is that index won’t be created until first query to that view. On some occasions (after inserting hundreds of thousands of documents) it might take even few minutes.

Although I covered only basics of CouchDB it should be enough for many applications. If you would like to learn more about the database I recommend you CouchDB – The Definitive Guide which is free to read.

• Backbone.js
• jQuery
• Require.js
• Lo-Dash
• Underscore.js

It’s a great start because if you are new to those technologies it’s really hard to guess what would be the best way to put everything together. I used it as a foundation to create an example App which talks to a PHP back-end.

The back-end could be a plain PHP but instead I went for the Slim micro framework. It’s fast, very easy to learn and will enforce a better code structure. After all, this is one of the best use cases for a micro framework.

Before I will go into details get a copy of the example from GitHub and install it on your web server.

$ git clone https://github.com/lukaszkujawa/api-based-application.git
$ cd api-based-application/
$ php composer.phar install
$ sudo vim /etc/apache2/sites-available/your-vhost

        ServerName 192.168.186.133
        ServerAdmin admin@localhost

        DocumentRoot /home/lukasz/projects/api-based-application/public

        
                Options Indexes FollowSymLinks MultiViews
                AllowOverride None
                Order allow,deny
                allow from all

                RewriteEngine On
                RewriteBase /
                RewriteRule ^index.php$ - [L]
                RewriteCond %{REQUEST_FILENAME} !-f
                RewriteCond %{REQUEST_FILENAME} !-d
                RewriteRule . /index.php [L]
        

$ sudo a2ensite your-vhost
$ sudo /etc/init.d/apache2 reload

When you open the page in your web browser you should see something like this:

A very minimalistic website with 3 links in the main content area. You can add some more if you follow the “create” link in the gray nav bar.

While you’re switching between pages to submit a new URL, notice that your web browser won’t reload. All front-end code is stored in JavaScript. When the web browser needs to talk to the web server it does it in the background with AJAX. It makes the application very responsive and limits number of requests.

To understand how it works lets have a look into “public/index.php“. The script defines 3 endpoints:

• $app->get(‘/link/latest‘, function () use ($app)
• $app->post(‘/link/submit‘, function () use ($app)
• $app->get(‘/‘, function() use ($app)

The first one returns a JSON object with all available links. In the real live it would look for them in a database but for the sake of simplicity I’m using a session. The second one handles POST request and stores links in the session. The last one is the simplest. It renders “templates/index.php” for all requests to the root “/”.

The template is an almost empty HTML5 file.

  <!--

  
  

  Backbone Boilerplate
  
  

  http://js/libs/require/require.js


  
  

The only interesting line here is:

http://js/libs/require/require.js

This is where the front-end gets initialised. It loads the Require.js library and refers it to js/main.js.

If you’re not familiar with Require.js it’s a module loader. Small but powerful library for breaking JavaScript code into multiple files/modules. If you want to learn only one new front-end framework this is where I would start. It has a good documentation and will help you organise your JavaScripts.

The next file we are going to look at is obviously “public/js/main.js”.

require([
  'views/app',
  'router',
  'vm'
], function(AppView, Router, Vm){
  var appView = Vm.create({}, 'AppView', AppView);
  appView.render();
  Router.initialize({appView: appView});  // The router now has a copy of all main appview
});

It loads 3 modules: views/app.js, router.js and vm.js.

Router.js is the heart of the application. It defines available pages and assigns them with the appropriate views.

var AppRouter = Backbone.Router.extend({
    routes: {
      // Pages
      'create': 'create',

      // Default - catch all
      '*actions': 'defaultAction'
    },

    instance: null

  });

The AppRouter extends Backbone.js router which is documented on the official website.

router.on('route:create', function () {
        require(['views/create'], function (CreateView) {
          console.log( "router::create" );

          var createView = Vm.create(appView, 'CreateView', CreateView);
          createView.render();
        });
    });

router.on('route:defaultAction', function (actions) {
      require(['views/index'], function (IndexView) {
        console.log( "router::defaultAction" );

        var indexView = Vm.create(appView, 'IndexView', IndexView);
        // indexView.render();
      });
    });

In this example we have only one custom route – “create“. It’s handled by “public/js/views/create.js“. Any other request will be resolved to the default action handled by “public/js/views/index.js“.

The index view does two things: initialise and render. When the object is initialised it’s calling LinksModel (public/js/models/links.js) model to fetch all links from the PHP back-end.

model: new LinksModel(),

initialize: function() {
        console.log( "controllers/IndexController::initialize()" );

        var context = this;

        this.model.fetch({
                success: function () {
                        context.render();
                }
            });

    },

Once a JSON object is successfully pulled from the web server the “public/templates/index/index.html” template is parsed and rendered with Lo-Dash template function.

render: function () {
        console.log( "controllers/IndexController::render()" );
        console.log( indexTemplate );
        console.log( this.model.toJSON() );

        this.$el.html ( _.template( indexTemplate, this.model.toJSON() ) );
}

The LinksModel I mentioned above extends Backbone.js model. Backbone models are the heart of any JavaScript application, containing the interactive data as well as a large part of the logic surrounding it: conversions, validations, computed properties, and access control. It’s a very useful and important entity so try to learn more about it.

define([
  'lodash',
  'backbone'
], function(_, Backbone) {

        var linksModel = Backbone.Model.extend({

           defaults: {
              links: []
           },

            url: "link/latest",

            initialize: function(){
                console.log("Links model init...");
            }

        });

        return linksModel;

});

In our example the model defines a data type called “links” which is an array and a URL “link/latest” to populate the defaults from.

As you can see it’s all quite simple. The only problem is that you have to embrace multiple JavaScript frameworks at once but the boilerplate makes it much easier. What I really like about this setup is the structure. It’s similar to how things are done in the back-end and it should be fine even with big applications.

I know that some developers feel anxious about writing one application in two languages simultaneously. I can sympathise with them because I prefer simple solution. The problem is that we like it or not, the web applications will have more and more JavaScript code. As the old saying goes – “if you can’t fight them, join them”. With the latest front-end frameworks you can improve user experience, cut hosting costs and have a well structured code. Single-page applications will probably become the industry standard in the next few years so you have all the reasons to give it a go.

The last sentence of the above paragraph is the key to sucess. It’s not only about what you have to do but also how are you doing it.

Make sure you’ve chosen the most effective way of learning. It will depend on your actual knowledge. Beginners might prefer direct interaction with people or follow video tutorials while experience developer could chose blogs, books or conferences.

Once you learn something new – practice it. It might require creating a proof of concept, a pet project or changing your habits. Stay curious and open minded. Don’t be afraid of breaking things. If you can check something yourself do it.

Although context of this post is PHP the question doesn’t have much to do with this particular language. Improving PHP skills means improving your universal programming skills. That can be broken down into 3 areas:
– engineering (coding standards, design patterns, unit testing, algorithms etc.)
– managing (application life cycle, version control, agile etc)
– environment (databases, operating system, networks, protocols etc)

Each person needs a different mixtures of the above skills – depends on what’s their ultimate goal. There are various senior positions for a developer but generally speaking all of them are either technical (head of development, senior architect etc) or commercial (development manager, CTO etc). The senior roles can be paid equally well so it’s a matter of choosing between science and business.

Ok, after this somewhat long introduction it’s the time to answer the question. To improve you PHP (or generally speaking web development) skills pick a point from the below list and try to learn as much as you can about it. You don’t have to follow the proposed order but ultimately you want to know everything from this list.

PHP programming
– PHP basics: variables, loops and functions
– Arrays (http://uk1.php.net/manual/en/book.array.php)
– File system functions (http://uk3.php.net/manual/en/ref.filesystem.php)

Font-end basics
– HTML
– CSS

Object oriented programming in PHP
– Classes and Objects (http://php.net/manual/en/language.oop5.php)
– Exceptions (http://www.php.net/manual/en/language.exceptions.php)
– Namespaces (http://www.php.net/manual/en/language.namespaces.php)

Database basics
– SQL basics (select, insert, update, delete)
– PHP PDO (http://uk3.php.net/manual/en/class.pdo.php)

Front-end
– JavaScript
– jQuery
– Responsive web design

PHP
– XML & DOM (http://uk3.php.net/manual/en/book.dom.php)
– Regular expressions (http://www.regular-expressions.info/tutorial.html)
– SPL (http://uk3.php.net/manual/en/book.spl.php)
– Magic Methods (http://php.net/manual/en/language.oop5.magic.php)
– GD (http://uk3.php.net/manual/en/book.image.php)
– JSON (http://uk3.php.net/manual/en/book.json.php)

Database
– Database design (http://en.wikipedia.org/wiki/Database_design)
– Indexing
– Maintenance (manage users, backups)
– SQL optimisation

Software design
– Design patterns (“PHP Objects, Patterns and Practice”)
– Algorithms and data structures (Introduction to Algorithms)
– Unit Testing (The Art of Unit Testing: with Examples in .NET)
– PHP Frameworks (one is enough)
– UML

Web application security
– MySQL injections
– Cross site scripting

Code managment
– Version control (SVN or GIT)
– Branching (http://nvie.com/posts/a-successful-git-branching-model/)
– Bug tracking (any available software)
– Coding standards (“Clean Code: A Handbook of Agile Software Craftsmanship”)

Linux
– Command line
– SSH
– Installation and configuration of LAMP environment
– Installing PHP extensions

Apache web server
– Virtual Hosts
– MOD_Rewrite

Alternative storage
– Caching: Memcached or Redis
– NoSQL: MongoDB or CouchDB or Cassandra
– Search engine: SOLR or ElasticSearch

Networking
– OSI Model (http://en.wikipedia.org/wiki/OSI_model)
– TCP/IP protocol
– HTTP protocol
– Working with sniffers (tcpdump or wireshark)
– CURL (http://uk3.php.net/manual/en/book.curl.php)

Leading development
– SCRUM (“Agile Project Management with Scrum”)
– Leading (“How to Lead: What the best leaders know, do and say”)
– Test Driven development

I would like this list to be as useful as possible so I will be extending it with the time. If you feel I missed something or you would like to recommend a good tutorial please let me know.

PHP by default stores session in a file. This might be OK with a single server architecture but if you have more than one web server than you need a centralised storage. Independently of your setup much better place for a PHP session is memcached. It will improve access time, scalability and of course – you will be able to access session from Varnish.

Storing session data inside the memcached is very simple to do with PHP.

$ sudo apt-get install memcached php5-memcached
$ sudo /etc/init.d/memcached start

Edit the php.ini file.

$ sudo vim /etc/php5/apache2/php.ini

Look for session settings

[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
session.save_handler = files

and change it to

[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
session.save_handler = memcached
session.save_path = "localhost:11211"

Now restart apache and it’s done.

$ sudo /etc/init.d/apache2 restart

If you like you can test it with the below code.

addServer('localhost', 11211);

foreach( $m->getAllKeys() as $key ) {
  printf( '
%s
', $key );
  var_dump ( $m->get( $key ) );
}

It should return something like this:

memc.sess.key.lock.78uso0onvumb665c1gm739er36

string

 '1' (length=1)
memc.sess.key.78uso0onvumb665c1gm739er36

string

 'test|s:11:"Hello World";' (length=24)

If it’s all working lets create a simple page which will simulate multilingual support.

<?php

session_start();

if( isset( $_POST['lang'] ) ) {
  print_r($_POST);
  $_SESSION['lang'] = $_POST['lang'];
}

$lang = isset( $_SESSION['lang'] ) ? $_SESSION['lang'] : 'English';

printf( "
My language is: %s (%s)
", $lang, time() );

?>



  
 English


  
 Spanish


  
 German

The idea is simple. If langues is set PHP will store it in session as “lang” and appropriate content will be displayed.

The challenge for Varnish is to create and return an appropriate cache based on selected language. Language is saved as a serialised string inside the memcached. It’s stored under “memc.sess.key.UNIQUE_KEY” where the UNIQUE_KEY is a value from the PHPSESSID cookie.

To access memcached from Varnish Cache script you have to install VMOD-Memcached. To compile this module you need Varnish source code.

$ wget http://repo.varnish-cache.org/source/varnish-3.0.3.tar.gz
$ tar zxfv varnish-3.0.3.tar.gz

Get the VMOD and all dependencies.

$ git clone https://github.com/sodabrew/libvmod-memcached
$ sudo apt-get install libmemcached-dev python-docutils
$ cd libvmod-memcached
$ ./autogen.sh 
$ ./configure VARNISHSRC=../varnish-3.0.3/
$ make
$ sudo make install

The extension should be copied into your Varnish vmod directory.

$ ls /usr/local/lib/varnish/vmods/ | grep memcached
libvmod_memcached.a
libvmod_memcached.la
libvmod_memcached.so

The last missing thing is the default.vcl file.

import std;
import memcached;

backend default {
  .host = "127.0.0.1";
  .port = "80";
}

sub vcl_init {
  memcached.servers({"--SERVER=localhost:11211 --NAMESPACE="memc.sess.key.""});
  return (ok);
}

sub vcl_recv {

  if (req.restarts == 0) {
    if (req.http.x-forwarded-for) {
      set req.http.X-Forwarded-For =
      req.http.X-Forwarded-For + ", " + client.ip;
    } else {
      set req.http.X-Forwarded-For = client.ip;
    }
  }

  if (req.request != "GET" &&
      req.request != "HEAD" &&
      req.request != "PUT" &&
      req.request != "POST" &&
      req.request != "TRACE" &&
      req.request != "OPTIONS" &&
      req.request != "DELETE") {
      /* Non-RFC2616 or CONNECT which is weird. */
      return (pipe);
  }

  if (req.request != "GET" && req.request != "HEAD") {
    /* We only deal with GET and HEAD by default */
    return (pass);
  }

  set req.http._sess = regsub( regsub( req.http.Cookie, ".*PHPSESSID=", "" ), ";.*", "" );
  std.log( "Cookie: " + req.http._sess );
  set req.http._sess = memcached.get( req.http._sess );
  std.log( "Session: " + req.http._sess );

  return (lookup);
}


sub vcl_pipe {
  return (pipe);
}

sub vcl_pass {
  return (pass);
}

sub vcl_hash {
  hash_data(req.url);
  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }

  if( req.http._sess && req.http._sess ~ "lang" ) {
    set req.http._lang = regsub( regsub( req.http._sess, ".*lang.*?x22", "" ), "x22.*", "" );
    std.log( "Lang: " + req.http._lang );
    hash_data( req.http._lang );
  }

  return (hash);
}

sub vcl_hit {
  return (deliver);
}

sub vcl_miss {
  return (fetch);
}

sub vcl_fetch {

  if( req.url ~ "^/$" ) {
    set beresp.ttl = 30m;
    remove beresp.http.set-cookie;
    return(deliver);
  }

  if (beresp.ttl <= 0s ||
    beresp.http.Set-Cookie ||
    beresp.http.Vary == "*") {
    /*
    * Mark as "Hit-For-Pass" for the next 2 minutes
    */
      set beresp.ttl = 520 s;
      return (hit_for_pass);
  }

  return (deliver);
}


sub vcl_deliver {
  return (deliver);
}

sub vcl_error {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  set obj.http.Retry-After = "5";
  synthetic {"
  ERROR
  "};
  return (deliver);
}


sub vcl_fini {
  return (ok);
}

There are few interesting things going on here.

sub vcl_init {
  memcached.servers({"--SERVER=localhost:11211 --NAMESPACE="memc.sess.key.""});
  return (ok);
}

As you probably can guess Varnish will connect to the memcached server on init.

Now look at the bottom of the vcl_recv function.

set req.http._sess = regsub( regsub( req.http.Cookie, ".*PHPSESSID=", "" ), ";.*", "" );
std.log( "Cookie: " + req.http._sess );
set req.http._sess = memcached.get( req.http._sess );
std.log( "Session: " + req.http._sess );

VCL language doesn’t allow to define new variables although you can reuse the predefined one (like in this example “req.http“). By the end of this block you should have the whole PHP session stored inside req.http._sess.

You can use

$ varnishlog | grep Log

to see output of the std.log function.

The most important code happens inside the vcl_hash subroutine.

if( req.http._sess && req.http._sess ~ "lang" ) {
  set req.http._lang = regsub( regsub( req.http._sess, ".*lang.*?x22", "" ), "x22.*", "" );
  std.log( "Lang: " + req.http._lang );
  hash_data( req.http._lang );
}

You can read more about VCL subroutines here but in a nutshell vcl_hash is responsible for building a hash string under which a cache is going to be saved.

By default Varnish is caching per URL and host but we have to extend it by a language name. This is exactly what happens here. A full hash string will look more less like this:

"/" + "localhost:8080" + "English"

The last thing worth explaining is what happens inside the vcl_fetch.

sub vcl_fetch {

  if( req.url ~ "^/$" ) {
    set beresp.ttl = 30m;
    remove beresp.http.set-cookie;
    return(deliver);
  }

If there is a cookie attached to a request Varnish will never return cached content. It comes from an assumption that if there is a cookie the page must be dynamic.

The point of this exercise if to handle dynamic content so we walk around this limitation for http://localhost:8080/ requests by unsetting cookies (it happens only in the Varnish scope).

Now you can start Varnish server (don’t forget to type start).

$ sudo varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,128M -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d
Platform: Linux,3.5.0-30-generic,x86_64,-smalloc,-smalloc,-hcritbit
200 244 
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,3.5.0-30-generic,x86_64,-smalloc,-smalloc,-hcritbit

Type 'help' for command list.
Type 'quit' to close CLI session.
Type 'start' to launch worker process.

start
child (4913) Started
200 0

Child (4913) said Child starts

Open two different web browsers, go to http://localhost:8080/ and start changing languages. POST requests are always forwarded to the web server so session value should be updated. For every GET Varnish should return an appropriate content (according to the current language selection) from cache.

It’s little bit tricky to set it up for the first time but the reward is worth it. Making the Varnish Cache aware of user’s status gives much more flexibility and allows to handle more requests directly from cache. That dramatically drops your hosting costs and increases capacity of your server. Give it a go.

You can install Varnish Cache via good old “apt-get” although I prefer to compile it from sources. The reason for that is I usually use it with memcached module which requires Varnish Cache source code.

Varnish requires libpcre.

$ sudo apt-get install libpcre3-dev

Install the software.

$ wget http://repo.varnish-cache.org/source/varnish-3.0.3.tar.gz
$ tar zxfv varnish-3.0.3.tar.gz
$ ./configure
$ make
$ sudo make install

If you didn’t use any –prefix= the software should be installed under /usr/local.

$ whereis varnishd
varnishd: /usr/local/sbin/varnishd

Config file should be in /usr/local/etc/varnish/default.vcl but it’s not that important.

Now it’s a time to create a very simple PHP script and save it as index.php.

Hello World

Cache from: 




  

    ESI is not working!
  

You might be wondering what is the ESI tag. It stands for Edge Side Includes and it’s a very cool feature.

A web page usually consists of multiple blocks. Some of them like layout change almost never while other might be fully dynamic. Varnish Cache allows to break down a page into such a blocks and cache them with a different expire time. Depends on your needs you can setup Varnish to pull those blocks from different web servers (for example you can have a dedicated host for a real time data).

Going back to our example Varnish will replace “” with a content from “/time.php“. Everything inside the

tag will be removed from the page.

Lets create the time.php script.

Cache from: 

It couldn’t be simpler.

Right now you should have 2 pages:

http://127.0.0.1/
http://127.0.0.1/time.php

Now it’s the time to create the varnish configuration file.

$ vim /usr/local/etc/varnish/default.vcl

backend default {
  .host = "127.0.0.1";
  .port = "80";
}

sub vcl_recv {

  if (req.restarts == 0) {

    if (req.http.x-forwarded-for) {
      set req.http.X-Forwarded-For =
      req.http.X-Forwarded-For + ", " + client.ip;
    } else {
      set req.http.X-Forwarded-For = client.ip;
    }
  }

  if (req.request != "GET" &&
      req.request != "HEAD" &&
      req.request != "PUT" &&
      req.request != "POST" &&
      req.request != "TRACE" &&
      req.request != "OPTIONS" &&
      req.request != "DELETE") {
      
      return (pipe);
  }

  if (req.request != "GET" && req.request != "HEAD") {
 
    return (pass);
  }

  if (req.http.Authorization || req.http.Cookie) {

    return (pass);
  }

  return (lookup);
}


sub vcl_pipe {
  return (pipe);
}

sub vcl_pass {
  return (pass);
}

sub vcl_hash {
  hash_data(req.url);

  if (req.http.host) {
    hash_data(req.http.host);
  } else {
    hash_data(server.ip);
  }

  return (hash);
}

sub vcl_hit {
  return (deliver);
}

sub vcl_miss {
  return (fetch);
}

sub vcl_fetch {
  if( req.url == "/") {
    set beresp.do_esi = true; /* Do ESI processing */
    set beresp.ttl = 120s; /* Sets the TTL on the HTML above */
  } elseif (req.url == "/time.php") {
    set beresp.ttl = 5s; /* Sets a one minute TTL on */
  }

  if (beresp.ttl <= 0s ||
    beresp.http.Set-Cookie ||
    beresp.http.Vary == "*") {

    set beresp.ttl = 120 s;
    return (hit_for_pass);
  }

  return (deliver);
}

sub vcl_deliver {
  return (deliver);
}

sub vcl_error {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  set obj.http.Retry-After = "5";
  synthetic {"
  
  
  
  
  "} + obj.status + " " + obj.response + {"
  
  
  
Error "} + obj.status + " " + obj.response + {"
  
"} + obj.response + {"
  
Guru Meditation:
  
XID: "} + req.xid + {"
  

  
Varnish cache server
  
  
  "};
  return (deliver);
}

sub vcl_init {
  return (ok);
}

sub vcl_fini {
  return (ok);
}

If you are new to Varnish Cache this might look little bit overwhelming but I assure you there is no magic here. This is the default configuration which is well explained in the manual. What’s interesting from our example’s point of view is inside vcl_fetch.

sub vcl_fetch {
  if( req.url == "/") {
    set beresp.do_esi = true; /* Do ESI processing */
    set beresp.ttl = 120s; /* Sets the TTL on the HTML above */
  } elseif (req.url == "/time.php") {
    set beresp.ttl = 5s; /* Sets a one minute TTL on */
  }

For the “/” request we turn the ESI processing on and we cache content from this location for 120 seconds. Content returned from “/time.php” will be stored only for 5 seconds.

Lets run varnish and give it a go.

sudo varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,128M -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d

Platform: Linux,3.5.0-30-generic,x86_64,-smalloc,-smalloc,-hcritbit
200 244 
-----------------------------
Varnish Cache CLI 1.0
-----------------------------
Linux,3.5.0-30-generic,x86_64,-smalloc,-smalloc,-hcritbit

Type 'help' for command list.
Type 'quit' to close CLI session.
Type 'start' to launch worker process.

One thing to notice is “-d” flag at the end of the above line. That will run Varnish Cache in debug mode so you have to type “start” to run it.

start
child (5101) Started
200 0

Child (5101) said Child starts

No open new tab in your web browser and visit http://127.0.0.1:8080/.

You should see something like that:

Hello World
Cache from: Sat, 06 Jul 13 22:20:47 +0100
Cache from: Sat, 06 Jul 13 22:20:47 +0100

Interesting thing happen when you refresh the page. First two line should stay the same for 2 minutes while the last one should change every 5 seconds. Isn’t that great?

This is not everything. There are cases when you have to invalidate cache without waiting for it to expire.

Varnish 3.x allows to ban cached data https://www.varnish-cache.org/docs/3.0/tutorial/purging.html. Modify the default.vcl file.

sub vcl_recv {
  if( req.url ~ "^/clearcache" ) {
    # for example /clearcache?uri=foo/bar

    if( req.url ~ "uri=" ) {
      ban( "req.url ~ ^/" + regsub( req.url, ".*uri=", "") );
    }

    error 200 "Ban added";
  }  

Obviously in the production environment you need additional condition to allow calling “/clearcache” only from certain IP addresses.

Stop Varnish server (ctrl + c) and start it again (don’t forget to type “start”).

$ sudo varnishd -f /usr/local/etc/varnish/default.vcl -s malloc,128M -T 127.0.0.1:2000 -a 0.0.0.0:8080 -d

Now if you go to http://127.0.0.1:8080/clearcache?uri= cache for “/” will be invalidated. You can see all active bans in you server console by typing ban.list.

ban.list
200 52 
Present bans:
1373146379.588119 1 req.url ~ ^/

Varnish will add bans only if there is a cached content (for that rule).

The last thing is to call the clearcache URL from PHP. After all we don’t want to manually refresh that page.

Lets create another script and call it clearcache.php.

 $val ) {
    curl_setopt( $ch, $opt, $val );
  }

  if( ! empty( $post ) ) {
    curl_setopt( $ch, CURLOPT_POST, 1 );
    curl_setopt( $ch, CURLOPT_POSTFIELDS, http_build_query( $post ) );
  }
  $output = curl_exec( $ch );

  if( $output === false ) {
    throw new Exception( curl_error( $ch ) );
  }

  $info = curl_getinfo($ch);

  curl_close( $ch );

  return $output;

  }
}

$ret = CURL::getUrl( 'http://127.0.0.1:8080/clearcache?uri=' );

if( preg_match( '/200 Ban added/', $ret ) ) {
  echo 'cache cleared'; 
} else {
  echo '
error
';
  echo $ret;
}

Now you can visit http://127.0.0.1/clearcache.php to give it a go.

If you need to troubleshoot your VCL script put

import std;

in the first line and echo data with

std.log( );

Debug data will be pushed to the Varnish Cache log and to read it run:

$ varnishlog | grep Log

Thank you for getting to the end of this post. Varnish Cache is a great peace of software and it’s worth knowing it. It’s little bit techie and programming VCL script could be easier but it will make your application fly.

There are many great tools you can use for benchmarking and finding bottle necks but the tools are not everything. If you want your results to be representative you need to follow the best practice. Doing a good science is a big subject far behind scope of this post. I can recommend four simple points which used to work for me.

• make sure there is no external traffic on a tested host
• always run benchmarks from a different host
• test form local network if possible
• monitor load (top, htop or dmesg will do) during a test

Apache Benchmark

This is my favourite tool. It’s very easy to use and you can find it everywhere. I usually go for a concurrency set between 20 and 100 and a minimum 500 requests. For example:

$ ab -n500 -c20 "http://example.com/"

Look at average requests per second. Higher is better.

Apache jMeter

Very rubost testing tool. If you want to know more about it read my previous post.

XDebug

Well known PHP extension for debugging and profiling. Profiling takes lots of resources so it’s better to use it on demand (trigger with XDEBUG_PROFILE=1 attached to a URL).

xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1

Profiler will save cache grinds to /tmp/ directory. You can use webbgrid to analyse it. It’s a very useful tool and it doesn’t require any configuration.

1. PHP accelerator

It has been iterated many times and I’m not very innovative here. This is the starting point. You can use APC or Zend Optimizer Plus. Bare in mind that the default configuration is not the fastest one. Both extensions will be looking into file timestamp to make sure the cache is up to date. Code doesn’t change spontaneously in a production environment so you can disable that feature. It will eliminate the slow fstat() calls but you will have to restart all web servers after every release.

2. Autoload with the Composer

Composer is designed to manage dependencies but it can also help with the performance. Even if a code is cached by an accelerator your framework can still try to call functions like “is_readable” and loop through the include_path. I had this particular problem with Zend Framework 1.12.1. You can quickly fix it by editing the composer.json file.

"autoload": {
        "classmap": ["application/", "library/"]

}

Classmap is an array so you can keep adding new paths. Run the composer to re-generate the autoloader.

$ php composer.phar update

The classmap is going to be cached by the APC so autoloading should get much faster.

3. Serialiaze heavy objects

Instantiating an object with a complex relationship might take a significant amount of time. A good example is Zend Framework’s router. The router is a collection of routes. Every route is an instance of “Zend_Controller_Router_Route”. Instantiating a route means executing route’s constructor (for every instance). Certain routes might be storing (chaining) other routes which adds to the execution time. Not to mention a configuration is usually stored in an XML or INI file which needs to be opened and parsed in the first place.

If the component is hermetic and doesn’t affect the environment you can skip the execution process and cache serialized object. Our goal is performance so cache it in RAM. When the instance is needed acquire it from a cache and unserialize it. Obviously the unserialize function doesn’t come without a cost. There are some opinions it can be sometimes slower than the normal approach. It might also vary accross different PHP versions. You can easly measure it with the mirotime function:

microtime(true);

In the router example I got a 10% improvement just with that one change.

It’s not difficult to achieve a major performance improvement on a not optimised code. The key to success is to measure everything and apply the 80-20 rule (80% of problems are in the 20% of code). XDebug profiler will instantly highlight where are the problems. Remember to profile against your production config.

Although I understand Anthony’s points I respectfully don’t agree with them. Currently I’m facing quite a big issue with the performance of ZF1 and PropelORM frameworks. Both are heavily abstracted and there is lots of inheritance in place. One request includes almost 300 files. Only 25% of those files are our code. Even if a controller is empty it takes significant time to handle a request (APC in installed and there is no I/O). This is a major concern to our business and we have some solutions in place to mitigate it.

It is common knowledge within the community that a vast majority of PHP application will never work under high traffic. However it is not only about requests per second but also user experience. According to Google (as mentioned in: “In The Plex: How Google Thinks, Works and Shapes Our Lives”) there is a correlation between load time and consumed content. Users will do more if they have to wait less. Google is very religious about making their service faster so why we all shouldn’t be?

While discussing Phalcon it’s easy to forget that performance is not the only feature. Phalcon is a full stack framework and can do a lot. It offers things like: ORM, query language, template engine, micro application front controller or very handy devtools. It’s all wrapped in a rich documentation with good examples.

The biggest problem I can see with C based frameworks is that there is no direct access to the source code. I completely agree with Anthony on this point. You can’t document everything and you won’t find all answers on Google. There will be situations when one have to debug something. It doesn’t happen often but once it happens it might be a dead end. If looking into a code written in C gives you a cold sweat perhaps Phalcon is not the best option for you. The good news is that, Phalcon’s source is well maintained. The file structure is intuitive and code is readable. Even a basic C knowledge should be enough to debug most of the potential issues.

We all know that PHP programmers don’t have a good PR. Things like Phalcon might cast a new light on the community and the language. For me it’s a step forward but Phalcon is going to have hard time. There are many strong PHP frameworks on the market. Many bloggers, speakers and lead developers invested lots of time in them. Suddenly there is a new kind on the block which makes those frameworks look little bit well… outdated. Things like this will always generate some emotions and programmers are emotional beings.

<?php
class ClassName {}

We can simplify the syntax and replace the curly brackets with semicolon.

<?php
class ClassName;

If you try to execute this code it will obviously throw an error. That’s not a problem, we can fix it.

First step is to install some software.

$ sudo apt-get install bison re2c

PHP is written in C however the parser is created with Bison. Bison is a parser generator. The home page defines it as: a general-purpose parser generator that converts an annotated context-free grammar into a deterministic LR or generalized LR (GLR) parser employing LALR parser tables.

It’s a very powerful peace of software and one can write a whole book about it. If you would like to learn more I refer you to the documentation. It’s not a very easy read but there is a good example. If you will ever want to create a programming language that might be the good place to start.

Go to the http://php.net and get the latest PHP sources.

$ tar xvjf php-5.4.14.tar.bz2
$ cd php-5.4.14
$ ./configure
$ cd Zend
$ ls

Take your hat off. You are looking at the core of PHP. Code in those files powers vast majority of web servers. Lets break it.

A default extension for Bison files is “y”.

$ ls *.y
zend_ini_parser.y zend_language_parser.y

We don’t want to mess with the “ini” syntax so the only choice is “zend_language_parser.y“. Open it with your editor of choice.

If you search for “class” you will find

%token T_CLASS      "class (T_CLASS)"

Parsers like to operate on tokens. The “class” token is “T_CLASS“. If you search for the “T_CLASS” you will find something like that:

class_entry_type:
    T_CLASS { $$.u.op.opline_num = CG(zend_lineno); $$.EA = 0; }
    | T_ABSTRACT T_CLASS { $$.u.op.opline_num = CG(zend_lineno); $$.EA = ZEND_ACC_EXPLICIT_ABSTRACT_CLASS; }
    | T_TRAIT { $$.u.op.opline_num = CG(zend_lineno); $$.EA = ZEND_ACC_TRAIT; }
    | T_FINAL T_CLASS { $$.u.op.opline_num = CG(zend_lineno); $$.EA = ZEND_ACC_FINAL_CLASS; }
    ;

You are looking at four different ways to define a class.

• class
• abstract class
• trait
• final class

In curly brackets you can see some low level assignments. I can only guess what are they for. Lets ignore them😉

We are on a right track but it’s not exactly what we’re looking for. Search for “class_entry_type” which groups those four definitions.

That takes you to the final destination. It’s easy but not very readable at the beginning.

unticked_class_declaration_statement:

    class_entry_type T_STRING extends_from
            { zend_do_begin_class_declaration(&$1, &$2, &$3 TSRMLS_CC); }
            implements_list
            '{'
            class_statement_list
            '}' { zend_do_end_class_declaration(&$1, &$3 TSRMLS_CC); }

    | interface_entry T_STRING
            { zend_do_begin_class_declaration(&$1, &$2, NULL TSRMLS_CC); }
           interface_extends_list
           '{'
          class_statement_list
           '}' { zend_do_end_class_declaration(&$1, NULL TSRMLS_CC); }
    ;

There are two declarations here. One for a class and one for an interface. We are interested in the first one. It starts with “class_entry_type” which resolves to: class | abstract class | trait | final class. Next element is a token T_STRING. That’s going to be the class name. Another element “extends_from” is a group. It can be “extends T_STRING” or nothing.

After that parser calls the Zend engine to begin class declaration.

{ zend_do_begin_class_declaration(&$1, &$2, &$3 TSRMLS_CC); }

You can find this function in zend_compiler.c file.

void zend_do_begin_class_declaration(const znode *class_token, znode *class_name, const znode *parent_class_name TSRMLS_DC)

First argument is a class token “class_entry_type“, second is a class name “T_STRING” and the last one is a parent class “extends_from“.

Under that we have another group “implements_list”. I’m sure you can guess it. Yes, it’s for assigning interfaces. Following lines define the mandatory class body: opening bracket “{“, “class_statement_list” group and the closing bracket “}“. Finally the parser informs Zend engine that the class declaration has ended.

{ zend_do_end_class_declaration(&$1, &$3 TSRMLS_CC); }

We need to duplicate that code but without class body definition.

unticked_class_declaration_statement:

    class_entry_type T_STRING extends_from
            { zend_do_begin_class_declaration(&$1, &$2, &$3 TSRMLS_CC); }
            ';' { zend_do_end_class_declaration(&$1, &$3 TSRMLS_CC); 

    | class_entry_type T_STRING extends_from

            { zend_do_begin_class_declaration(&$1, &$2, &$3 TSRMLS_CC); }
            implements_list
            '{'
            class_statement_list
            '}' { zend_do_end_class_declaration(&$1, &$3 TSRMLS_CC); }

    | interface_entry T_STRING
            { zend_do_begin_class_declaration(&$1, &$2, NULL TSRMLS_CC); }
           interface_extends_list
           '{'
          class_statement_list
           '}' { zend_do_end_class_declaration(&$1, NULL TSRMLS_CC); }
    ;

It was quite simple, wasn’t it? Now you just have to compile it.

$ cd ..
$ make

First compilation is always taking a while.

$ vim test.php

Paste the test code.

bar = 10;

print_r( $a );

Go and test your hack.

$ sapi/cli/php test.php 
Bar Object
(
[bar] => 10
)

Well done, you’ve hacked PHP!

Lets add one more thing. In PHP you define a class with the “class” keyword. How about make it shorter? “cls” should do fine.

Look for Lexer files.

$ cd Zend/
$ ls *.l
zend_ini_scanner.l zend_language_scanner.l

Bison file was operating on tokens. Lexer allow you to define how to convert a code into the tokens.

Opens zend_language_scanner.l and search for “class“.

"class" {
return T_CLASS;
}

Duplicate this block and change class to cls.

"cls" {
return T_CLASS;
}

"class" {
return T_CLASS;
}

Job done. Compile the code and you can use “cls” instead of the “class” word.

Wasn’t that fun? I hope you enjoyed it as much as I did. Play around, break it. If you really like it think about closing some bugs on https://bugs.php.net/.

I benchmarked “quick start” projects. That gives some idea on what is the base line for every framework and makes it possible to reproduce my tests (and argue against them).
Code was hosted on Amazon EC2 medium instance. I installed PHP-APC to avoid disc access and code parsing. I also made sure there is no I/O on Apache2 or application level. I set logs and cache paths to “/dev/shm/”. I tweaked projects to make them return roughly the same amount of data (10KB). All virtual hosts had the same mod_rewrite rules. AllowOveride was set to None.

Benchmarked frameworks:

• Cake PHP
• Code Igniter
• Fuel PHP
• Hazaar MVC
• Kohana
• Laravel
• Netter
• Phalcon
• Silex
• Slim Framework
• Symfony 2
• YII
• Zend Framework 1
• Zend Framework 2

Requests per second from Apache Benchamrk with c=20 and n=500.

I’m not surprised, Slim is the fastest because it’s a micro framework. The Quick Start project didn’t use any templates or layout which obviously contributed to the reading.
Zend1 is twice faster than Symfony2 and Zend2 but in my experience the number will quickly go down in a real live setup.

Frameworks should speed up development, performance is a secondary concern. Zend 2 and Symfony2 could do better but it’s not bad. There are ways to improve those numbers on production servers. Don’t reinvent the wheel, learn and use frameworks. There are various options which balance between performance and features.

ps. If you have space for more I would like to recommend you great research on performance of web frameworks by techempower.

ps2. Thank you for your suggestion Ron. Phalcon is the new winner.