PHP/APC effectiveness – just a teaser

May 14th, 2011

There’s a task to implement REST-backend to handle user’s keystrokes. The low latency is critical.

The main overhead of REST is caused by two factors: decoding URL to find a handler and loading handler code. In PHP we have to include and interpret the code on every request so both loading all services on each request would become unacceptable expensive solutions.

Elegant way to solve the problem suggested by Jacob’s Simpl Rest Server and using APC.

The very first REST-reuest triggers including a PHP file (spl_autoload_register) what contains the code needed for this request, creates an instance of handler class and put this instance in cache alongside with the URL forming an entry in hash-table. Each next request hist this hash table with URL, pickups the existing instance and call its method without any need to read/interpret PHP-source code.

See the result:

Code review implementation

May 13th, 2011

Web development is outstanding from the point of view of organization. It should be fast, inexpensive, there’s no place for refactoring. To meet these challenges the code review is extremely important.

We use Atlassian Fisheye+Crucible for daily code analyze. It is essential solution, but we had troubles with implementation for a long time. The J2EE apps are like russian oligarchs: first they take everything what belongs to nobody, next start to smash each other. We have Atlassian Jira, Confluence, test webservers, some other services and an attempt to rent one big server failed with financial disaster and unstability. The solution was found in opposite direction: Amazon EC2 small instances. Each of them is dedicated for one J2EE app and internal network used for communication among them. Few EC2 instances still are chipper than one hi-end server and ideal for the only java app.

There was another problem though – Fisheye need to monitor SVN repository pretty often and with svn or even http protocol each scan takes forever. Having internal Amazon Cloud network we gain ability to mount repository as read only NFS volume and use file protocol which runs much more faster than others do.

ExtJS 4: the only right way to use association

May 13th, 2011

4th version seems to have many very promising features and new Association class is not least among them. But as almost everything it does not work. Samples from guides raises lot of vague error messages and stop application working. Looks like the architector of the library changed his mind few times and the coders did not understood his ideas either.

For beginning the only Association class play two different roles: a wrapper for compound objects read from proxies and a tool to handle relation databases. It is not bad idea but implementation is terrible. The same API interpreters the same parameters in very different ways in returns absolutely different results.

Just take a look at this:

The next problem is the comrades messed up Ext.loader ability to look for classes by names with simple class managers which require exact full path.

But hands on. Let it be a data like this:

[{
    id: 1,
    site: 'www.armour.up',
    component: {
      id: 2,
      name: 'theme'}
 },{
    id: 3,
    site: 'www.armour.up',
    component_id: 4
    component: {
      id: 4,
      name: 'plugins'
    }
}]

I.e. two instances on site description which contain component description objects inside them. The model to handle this stream as whole is:

Ext.define('D.model.Deploy', {
  extend: 'Ext.data.Model',
  alias: 'model.deploy',
  fields:[{
    name:'id', type: 'int'},{
    name:'site', type: 'string'},{
  }],
  associations: [{
    type: 'belongsTo',
    model: 'D.model.Component',
    associatedName: 'Component', 
    instanceName: 'component' 
  }],

The magic is to give associations options right values.
model must be full path to a model class of bound object – it will be used to create instances;
associatedName – this is base for generating bunch of names:

name        : associatedName,
foreignKey  : associatedName.toLowerCase() + "_id",
instanceName: associatedName + 'BelongsToInstance',
associationKey: associatedName.toLowerCase()
getterName     = me.getterName || 'get' + associatedName,
setterName     = me.setterName || 'set' + associatedName;

I do not like default value of instanceName – the name of the model field which will hold child model and change it explicitly.

There’s nothing special besides that. The instances of Deploy models will have instances of D.model.Component accessible either by property .component(record.ComponentBelongsToInstance) or with method record.getComponent().

But everything change if proxy provides typical relation database data:

[{
    id: 1,
    site: 'www.armour.up',
    component_id: 2
    },{
    id: 3,
    site: 'www.armour.up',
    component_id: 4
}]

Association model become more verbose:

  associations: [{
    type: 'belongsTo',
    model: 'D.model.Component',
    associatedName: 'D.model.Component',
    getterName: 'getComponent',
    name: 'component',
    foreignKey: 'component_id',
    instanceName: 'component'
  }]

The troubles caused by one small piece of code where associatedName used to create model instance. Because of that it must be full name. Needless to say the dotted name can not be used anymore as base for the others. The getter name for example turns into getD.model.Component. Beside necessity of naming all parameters the foreignKey must be added as well.

The change in associations description is not all. A function getComponent behaves absolutely diffrently. It becomes void but accepts pretty fancy parameter built from couple functions - one will be called on success of pulling data for inner model and the other in case of failure:

  record.getComponent({
      success:function(a,b){console.log(a);console.log(b)}
      failure:function(a,b){console.log(a);console.log(b)}
    });

ExtJs 4: setting store model bug

May 12th, 2011

An attempt to set model of the store in the way described in docs:

// we have a store "Deploys"
Ext.define('D.store.Deploys', {
  extend: 'Ext.data.Store',
// which uses model "Deploy"
  model: 'Deploy',
  data: [{
...
  }]
});

fires this:

Some meditation over source code suggested a solution which helps:

Ext.define('D.store.Deploys', {
  extend: 'Ext.data.Store',
// it is necessary to set
// full path of the class
  model: 'D.model.Deploy',
  data: [{
...
  }]
});

ExtJS was a brilliant sample of “it works!” software. I beloved it. Now the Sencha turns into worktime killer and goes the way of YUI3: even demos from the main site do not work. It is a pity.

1 2 3 4 5   »