Articles

2009-05-30

Framework Benchmarks: LightRail, CakePHP, CodeIgniter, Symfony and Zend

Here is a demonstration of how LightRail's speed stacks up against popular PHP application frameworks.

First is the classic benchmark of an application framework outputting a simple web page which says "Hello World". Layout templates were used with the exception of CodeIgniter as it did not have built-in layout support.

The results are posted in requests served per second with higher numbers representing better performance.



Next is a benchmark of each framework using its object relational mapping implementation to read a couple dozen database records.



Of course you don't need full ORM just to read records. Using LightRail's built in support for PHP Data Objects to perform the same test it served 104 requests per second.

LightRail enables your hardware to serve higher web site traffic volume and keep delays to a minimum while still benefitting from the structure an application framework provides.

2009-05-22

Beta Release of LightRail Web Application Framework

This article section has been quiet for altogether too long so it is fitting that it is good news which breaks the silence. I am pleased to announce the beta release of the LightRail web application framework.

It was not my intention to build yet another application framework but after experimenting with many of the popular projects I felt a need to break with the pack, especially after benchmarking Zend Framework.

Not that Zend is a poor framework. It is nothing if not comprehensive, but like other frameoworks it makes your hardware labour, even for simple tasks. And I have yet to meet anyone who wants a site that becomes unresponsive as traffic picks up.

So I started building a PHP application framework with two goals in mind: it had to provide enough structure to simplify development and it also had to remain light and speedy. LightRail is the result.

Stay posted for benchmarks. Or download a copy and run some yourself. This thing is FAST.

2009-05-19

Security versus Features - what you probably didn't want to hear

This article could also have been named "Real life versus pie in the sky" and I don't imagine it will win me much popularity, otherwise the material herein would long ago have made it into public advertising.

There is a very good reason why Windows Vista plagues the user with an unending stream of security dialogue pop-ups. Nobody in Redmond was slamming his fist on the boardroom table saying "Let's annoy our user base for no good reason!"

The early versions of Windows were released in a more trusting time, a fact also reflected in other operating systems of that era. One of the things which made it attractive to build software for Windows was the wide range of API's which gave developers generous access to the user's system. These hooks into the system were made available everywhere: user installed software, remote access calls, emails, even web pages! This introduced a wave of application development but it also introduced an era of poor practices.

Queu the hackers. A lot of applications granted themselves administrative access even when it was not necessary. The result was that a hacker could obtain full access to the user's machine by finding an exploit in one of those programs. Users have been trapped in a virtual turkey shoot ever since. Some of the worst API hooks have already been removed. (e.g. incoming email having full access to the user's system) While this has removed some very creative possibilities it has been an absolute necessity.

So how does this relate to web applications? For one thing, the default settings in Internet Explorer have changed so that the entire internet is no longer granted administrative access to a user's computer. I will tell you, a chill ran down my spine back when I first saw how trivial it was to create a web page that could delete critical system files from Windows. That should never have been a possibility but the rush for features obviously superseded long term planning.

Holes have also been found with numerous other web technologies that execute on the client side. And client side execution is popular. You may have heard about AJAX, Flash or applets, all of which execute on the user's computer and inside their firewall. The model itself is flawed and fundamentally unacceptable from a security point of view. I have witnessed some chilling proof of concept code and model attacks. The same technology which supports “drag-and-drop” on web pages can silently cough up your credit card numbers, internal network details or the login for your bank.

The most obvious solution is to nip the problem in the bud and discontinue the path of web delivered client side execution. Continue to use pages and forms (submitted when you decide to) and let execution occur on the remote server, outside your firewall. This gives users the ability to remove vulnerable technology. But sleek sells. In all likelihood we will address problems one at a time and only after serious hacks have occurred.

My own approach is once again to layer technologies. I prefer to have it so that the heart of the web application can function without client side execution. That way users are permitted to make themselves less vulnerable if they so choose. Then client side technology can be layered on top so that the average user (who is unwittingly intrepid) gets their eye candy.

2007-09-26

Hardware Costs vs. Development Costs

Anyone who wants to launch a web site has to determine the costs.

So how much do you weigh the cost of development time against the cost of hardware to deploy the site?

If you only require a couple pages of dynamically generated content it is simple to manage these items. But the more depth the site acquires the more important it is to build it on a foundation which scales to the programmatic expansion, otherwise your development time will begin to balloon disproportionately for each new feature or update.

Unfortunately using a scalable application development framework can make more demands of your hardware and if the site becomes busy you may need to upgrade your server(s).

The general thought is that hardware is cheaper than development time. However, inefficient programming can bring a lot of hardware to its knees if there is a traffic spike.

I think a compromise is in order. It behooves those of us who develop frameworks to take some time to consider the hardware. Just not too much time. Time is money. And these days hardware is relatively cheap.

2007-07-10

Want to be iPhone compatible?

How would you like a ground level opportunity to market applications for the iPhone? I have good news for you.

Instead of releasing an iPhone API Apple has chosen to make their product compatible with the existing internet. Well, a large part of the existing internet anyway. Apple's Safari browser, included in the iPhone, is built on a rendering engine which is very compatible with the official standards of the world wide web consortium. Good news for people who want a reliable internet.

The down side is that the Internet Explorer browser bundled with Microsoft Windows was so predominant during the last decade that many web sites are not ready for advanced, standards compatible browsers like Safari and Firefox.

The up side is that there is a window of opportunity for organizations which do have sites that are compatible with iPhone. And if it's compatible with the iPhone, it's pretty much compatible with everything else. That's the strength of standards.

2007-07-10

Fuzzy Data: Google, Inflectors, Artificial Intelligence and You

It has been suggested that the future internet could use artificial intelligence to make sense of vague and/or fudged URL requests. I highly doubt the global DNS is about to embrace such a concept (and the increased processing) but it does bring up a topic dear to anyone who has ever created a User Interface: how do you deal with vague or fudged input?

The above example is moot since one can already enter any vague thought at Google and click "I feel lucky". But it is also a classic example of dealing with imprecise user input. If you are like me and you regularly like to test the spell checkers (I maintain my poor spelling is on perpus) you will no doubt have noticed search engines making alternate suggestions at the top of your searches from time to time, especially if you have botched a word or used one which may have alternate spellings.

Now enter a service like Google Mail. Apply the power of an advanced search engine to your email and suddenly the issue of organizing that email is trivialized. If you want to reference a message you can just search for it using whatever neural reference jarred your memory about it in the first place.

At least that's the theory. Of course it isn't perfect in practice even if it is pretty good. Either the search engines need to learn to think more like we do or we need to think more like the search engines do. And young people growing up in the computer era are indeed thinking more like machines. Perhaps more vigilant monitoring will also teach search engines more about the way your brain works.

For those of us who do not have access to the immense resources of a Google or Microsoft the matter of developing algorithms to deal with imprecise or mistaken user input often runs up against the time constraints of realistic development cycles. It seems to me that we either need access to plug-able third party tools or else we need to demand valid input.

Let me give an example: it is fairly easy to offer the user a pull down menu containing all the states or provinces relevant to a given form. That ensures valid formatted input without requiring advanced programming. But if the form relates to a large geographic area it is probably not realistic or bandwidth-friendly to provide a pull down menu with the names of every town and city. Are there third party libraries which can cross reference user input against a database of known cities to check for common spelling errors? Should we even bother to develop such a thing?

What about names? This one drives me nuts. You have one person enter a customer as Joe Dirt. The next looks for Joseph Dirt and doesn't find him so they create a new entry for the same customer! By the time "Joey" ends up in the database you have a real problem. As a geek I want to say to the customer "why don't you just give me your social insurance number or at least your phone number?" As a customer who faces this regularly (and understands it's always so they can track me in some database) I want to ask "Would you care to give me YOUR social insurance number?"

Do we build huge inflectors which equate every variation of every name encompassed by the human tongue? Less huge inflectors which catch the most common variations of common names? Do we require DNA samples so names are irrelevant?

Or do we allow users to make mistakes?