Threading / Blocking vs Event Driven Servers (and Node.js)

April 9th, 2011 No comments

I was just reading an old (Nov 2009) article by Simon Willison (of Django, The Guardian and Lanyrd Fame) discussing the emergence of Node.js.

Two of the things in particular I found interesting about the article:

Firstly, he cleverly predicted the importance and future popularity of Node.JS – and boy was he right. A year and a bit later and Node.JS is everywhere. I don’t think a day ever goes by when I don’t see at least one mention and/or article about it.

Secondly, he has a brilliant (and simple) description of threading / blocking servers vs event driven servers (just like Apache vs Nginx).

Event driven servers are a powerful alternative to the threading / blocking mechanism used by most popular server-side programming frameworks. Typical frameworks can only handle a small number of requests simultaneously, dictated by the number of server threads or processes available. Long-running operations can tie up one of those threads—enough long running operations at once and the server runs out of available threads and becomes unresponsive. For large amounts of traffic, each request must be handled as quickly as possible to free the thread up to deal with the next in line.

This makes certain functionality extremely difficult to support. Examples include handling large file uploads, combining resources from multiple backend web APIs (which themselves can take an unpredictable amount of time to respond) or providing comet functionality by holding open the connection until a new event becomes available.

Event driven programming takes advantage of the fact that network servers spend most of their time waiting for I/O operations to complete. Operations against in-memory data are incredibly fast, but anything that involves talking to the filesystem or over a network inevitably involves waiting around for a response.

With Twisted, EventMachine and Node, the solution lies in specifying I/O operations in conjunction with callbacks. A single event loop rapidly switches between a list of tasks, firing off I/O operations and then moving on to service the next request. When the I/O returns, execution of that particular request is picked up again.

You can read the full article here: Node.js is genuinely exciting.

If you are not familiar with Node.js (have you been living under a rock for the past year?? :) ), there is a great video by the author, Ryan Dahl here:

Categories: Interesting Tags:

Why Can’t Developers Estimate Time?

April 9th, 2011 1 comment

Ashley Moran just wrote an interesting article about why developers can’t estimate time.

Something most developers find hard is estimating the time something will take.

If it’s something you have done before, a repeatable task, then it’s easy – although most of the time things take longer than you think they will when you think it through in your head and quite often it turns out to be more complicated than you thought when you get into it or you hit a bug of some kind that you end up having to debug which takes a long time and compounds the issue.

Sometimes the problem of bad estimates is made worse is when estimates (which are at the end of the day an educated guess) are taken as a promise and therefore if it takes longer then there is a feeling that it should have been done quicker.

I particularly found these quotes interesting and amusing:

We can’t estimate the time for any individual task in software development because the nature of the work is creating new knowledge.

Rule of thumb: take the estimates of a developer, double it and add a bit

The double-and-add-a-bit rule is interesting. When managers do this, how often are tasks completed early? We generally pay much more attention to overruns than underruns

Categories: development Tags:

Faster Broadband – BT Infinity (Fibre to the Cabinet) Coming to Ingleby Barwick – How does it work?

April 7th, 2011 No comments

I first learned about BT Infinity last year when a friend I used to work with at BT pointed out that my exchange, Ingleby Barwick had been scheduled to be enabled in June 2011. At the time that sounded a long time away but now it’s getting closer, I decided to do a bit of digging and find out technically how it worked.

BT Infinity is BT’s new Fibre To The Cabinet (FTTC) broadband service which is slowly being rolled out across the country and promises speeds of up to 40Mbps downstream and 10Mbps upstream.

Pretty much all of the country can now get broadband in the form of ADSL (Asymmetric Digital Subscriber Line). ADSL works by utilising the existing copper wiring for the telephone lines already in the majority of homes. Unused frequencies are utilised to send data over the lines and a splitter is placed on the customers phone sockets to split the broadband signals off and allow simultaneous use of the telephone and broadband.

The original ADSL standard gives a theoretical maximum downstream speed of 8Mbps and upstream speed of 1Mbps and the newer ADSL2+ standard gives a theoretical maximum downstream speed of 24Mbps and upstream speed of 3.3Mbps. I say theoretical because it’s practically impossible to ever obtain those speeds unless you are literally next door to the exchange. The majority of people only obtain a fraction of those speeds. I am reasonably lucky to be able to be able to get 5Mbps downstream and just under 1Mbps upstream – most people I know get even less than that. (My modem actually sync’s at around 6000kbps and 1000kbps but only get around 5Mbps and just under 1Mbps real world speed test). The reason for this is that when transmitting signals over long distances of copper wire, noise on the line degrades the signal and the maximum speed reduces. As the exchange can be miles away from the premises and cable ducts do not necessarily even run directly as the crow flies, this loss can be great. It’s also very very sensitive to dodgy wiring – for this reason it’s recommended to plug the modem/router into the master socket and use a filtered faceplate to filter off the ADSL signal before the extension wiring to minimise the risk of interference (which is exactly what I do).

The only other serious option for fast home broadband in the UK is if you are in the coverage area for Virgin Media’s Cable Internet service. I used to have cable internet for several years – however when we moved house, even though it was less than 5 minutes walk round the corner, our new street is not wired for cable. There is a Virgin Media cabinet opposite our road end but they have not cabled down the street. If you can get cable then you are able to obtain speeds of up to 100Mbps downstream and 10Mbps upstream through their latest packages. The good thing about cable internet is when you sign up for a certain package, be it 10Mbs, 20Mbps, 30Mbps, 50Mbps or 100Mbps, you do actually get that speed connection. Of course, with connection in NTL’s network and quite harsh traffic management (throttling) they apply at peak periods, you wont necessarily see those real life download speeds all of the time, but at least you are actually connected at the speed you are paying for. The way this is achieved is, Comcast as they were known when they first started laying cables (they were later sold to NTL and later to Virgin), similar to BT, distributed cabinets around their coverage area to interconnect users. However, unlike BT, Comcast ran fibre optic connections to their cabinets rather than huge quantities of copper wires (one pair per line). What they then do is lay low-loss coaxial cable (coax) between the nearest cabinet and the premises. A single length of coax can provide the subscriber with fast broadband and cable television.

With ADSL, a modem at the customers premises (usually ISP’s supply a combined ADSL modem and router so the single connection can be shared between several machines connected via ethernet or 802.11 wireless using NAT (Network Address Translation) which allows multiple computers on a Local Area Network (LAN) to communicate to the internet with a single external IP address) connects to the ADSL splitter and over the copper wire direct to DSLAM equipment in the telephone exchange.

With BT’s new FTTC network (BT Infinity), as it’s name suggests, the local cabinets are connected via fibre (optics) back to the telephone exchange (which I assume will be connected by fibre to BT’s core network). As fibre travels at the speed of light, there is negligible loss – hence why it’s also used to connect different countries together round the world.

When I first heard about it, I didn’t really think about it and assumed that they would do similar to Virgin’s cable service and lay new cables of some kind between the cabinet and the customers premises. When you actually think about it though, that would be expensive, slow to roll out and would end up like Virgin’s cable network – severely limited to certain areas. i.e it wouldn’t really be practical.

So, how does it work? – well, what they are doing is using a technology called VDSL which is similar to the current ADSL technology already in use.

What this means in reality is the following:

Once the exchange has been enabled for FTTC, they will distribute new and slightly bigger cabinets which will house DSLAM equipment which is similar (but newer) to that currently housed in the telephone exchange, the fibre backbone, patch panels and a cross connect to the existing BT cabinet.

When you order BT Infinity, an engineer will come out to install the product. He will replace your current master socket with a new NTE5 master socket with a built in filter (so the modem/router will need to go into the master socket as the broadband frequencies will be split off before the extensions). He will then hook up a VDSL modem and separate “BT Home Hub” router.

What this modem does is connects using VDSL from your home to the VDSL cabinet using the existing copper wires, on to the DSLAM, back to the exchange (over the fibre) and on to BT’s core network.

Your phone line is then still terminated in the original cabinet for telephony (using the cross connect between the old and new cabinets I mentioned above) and back to the exchange over the original multi pair copper cable as it always has done.

What this means is that the noise induced loss is now only an issue between your premises and the cabinet rather than your premises and the exchange. This is how they are able to provide the quoted maximum speeds of 40Mbps downstream and 10Mbps upstream and you are much more likely to be able to get somewhere near these speeds depending on the distance to your cabinet and the quality of the lines and wiring to it.

Another area worth mentioning is currently, any ISP (Internet Service Provider) can sell you ADSL broadband. They either do this by using BT’s network and renting from their wholesale devision (I believe the product is called IPStream) or renting space in their exchanges and installing their own equipment (known as LLU). I believe this will still be possible with the new FTTC network but there doesn’t yet seem to be a great uptake in this – probably due to the costs involved.

Disclaimer: This is only my own knowledge mixed with snippets i’ve read about FTTC rather than any inside information so please do feel free to comment if you know anything here to be incorrect.

Categories: Phones Tags: , , ,

Book Review: Sphinx Search Beginner’s Guide

April 5th, 2011 No comments

Packtpub were kind enough to send me a copy of their new book, Sphinx Search Beginner’s Guide to review.

The book is written by Abbas Ali who is currently working as Chief Operating Officer and Technical Manager at SANIsoft Technologies Private Limited, Nagpur, India. The company specializes in development of large, high performance, and scalable PHP applications.

Sphinx is well described by it’s website as follows:

Sphinx is an open source full text search server, designed from the ground up with performance, relevance (aka search quality), and integration simplicity in mind. It’s written in C++ and works on Linux (RedHat, Ubuntu, etc), Windows, MacOS, Solaris, FreeBSD, and a few other systems.

Sphinx lets you either batch index and search data stored in an SQL database, NoSQL storage, or just files quickly and easily — or index and search data on the fly, working with Sphinx pretty much as with a database server.

The book covers everything from the installation and setup of Sphinx to simple and advanced use in PHP.

Here is a full outline of what’s covered:

  • Chapter 1, Setting Up Sphinx is an introduction to Sphinx. It guides the reader through the installation process for Sphinx on all major operating systems.
  • Chapter 2, Getting Started demonstrates some basic usage of Sphinx in order to test its installation. It also discusses full-text search and gives the reader an overview of Sphinx.
  • Chapter 3, Indexing teaches the reader how to create indexes. It introduces and explains the different types of datasources, and also discusses different types of attributes that can comprise an index.
  • Chapter 4, Searching teaches the reader how to use the Sphinx Client API to search indexes from within PHP applications. It shows the reader how to use the PHP implementation of the Sphinx Client API.
  • Chapter 5, Feed Search creates an application that fetches feed items and creates a Sphinx index. This index is then searched from a PHP application. It also introduces delta indexes and live index merging.
  • Chapter 6, Property Search creates a real world real estate portal where the user can add a property listing and specify different attributes for it so that you can search for properties based on specific criteria. Some advanced search techniques using a client API are discussed in this chapter.
  • Chapter 7, Sphinx Configuration discusses all commonly used configuration settings for
    Sphinx. It teaches the reader how to configure Sphinx in a distributed environment where
    indexes are kept on multiple machines.
  • Chapter 8, What Next? discusses some new features introduced in the recent Sphinx release.
    It also shows the reader how a Sphinx index can be searched using a MySQL client library.
  • Lastly, it discusses the scenarios where Sphinx can be used and mentions some of the
    popular Web applications that are powered by a Sphinx search engine.


At first, the style of the book seemed a bit strange to me – it’s split up into small chunks which are often followed by a “What just happened” section which gives a summary or broken down explanation of the concept just explained. Once I got used to it though, this actually improved the clarity and aided understanding.

The book is a very informative read for both beginners to either search or Sphinx and existing users and i’d highly recommend it to anyone interested in either search or the Sphinx product.

Anyone willing to find out more about or purchase the book can do so on the Packetpub website.

Categories: Reviews Tags: , , , ,

HTML5 Boilerplate Reaches v1.0

March 21st, 2011 No comments

This afternoon sees the HTML5 Boilerplate project (H5BP), led by Paul Irish, reach it’s much anticipated v1.0 release.

If you have not heard of the HTML5 Boilerplate (or H5BP as they started calling it recently) before, it’s an excellent and essential resource for web developers. It can either be used as a complete starting point for a new web project or as a large collection of cross browser recipes and best practices to incorporate into your existing projects.

To quote from the HTML5 Boilerplate Website:

HTML5 Boilerplate is the professional badass’s base HTML/CSS/JS template for a fast, robust and future-proof site.

After more than three years in iterative development, you get the best of the best practices baked in: cross-browser normalization, performance optimizations, even optional features like cross-domain Ajax and Flash.

A starter apache .htaccess config file hooks you the eff up with caching rules and preps your site to serve HTML5 video, use @font-face, and get your gzip zipple on.

Boilerplate is not a framework, nor does it prescribe any philosophy of development, it’s just got some tricks to get your project off the ground quickly and right-footed.

Today’s release of v1.0 isn’t just a bump from the Release Candidate to the final version, it also brings with it some exciting new material:

  • A Boilerplate Custom Builder – providing a custom package with only the features you require (similar to Paul’s previous Modernizr builder.
  • Improved Documentation
  • Improved Build Script
  • New video guides
  • Support for lighttpd, Google App Engine and Node.JS
  • Reduced size (50% smaller!)

You can find out more about the Boilerplate by watching the following videos. The latter is particularly entertaining and Paul is a great presenter.

Categories: development Tags: ,

DOM Monster

March 17th, 2011 No comments

There is an interesting new JavaScript tool circulating today – DOM Monster.

DOM Monster is our answer to JavaScript performance tools that just don’t give you the full picture.

DOM Monster is a cross-platform, cross-browser bookmarklet that will analyze the DOM & other features of the page you’re on, and give you its bill of health.

If there are problems, DOM Monster will point them out—and even make suggestions on how to fix ‘em.

You can read more and get it from here.

Categories: development Tags: , ,

Logging to Syslog with Kohana 3

March 16th, 2011 No comments

By default, the Kohana PHP Framework logs errors to files in the application/logs directory, separated into directories and files for each year, month and day (eg: application/logs/2011/03/16.php).

To change this behaviour to use the system log daemon, you change the following line in bootstrap.php:
Kohana::$log->attach(new Kohana_Log_File(APPPATH.'logs'));
to:
Kohana::$log->attach(new Kohana_Log_Syslog('site_identifier', LOG_LOCAL1));

By default, these will probably appear in your /var/log/syslog file (on Debian/Ubuntu anyway – some other distributions use /var/log/messages).

You can configure syslog to put these in their own file by adding this to your syslog configuration file (on Debian/Ubuntu it’s done by adding a file into /etc/rsyslog.d):
local1.* /var/log/local1.log

If something else is already logging to local1, you can change that and LOG_LOCAL1 above to local2 and LOG_LOCAL2.

If you would like to write your own messages to the log, you can do so with:
Kohana::$log->add(Log::ERROR, 'error text');

Instead of ERROR, you can also use EMERG, ALERT, CRITICAL, WARNING, NOTICE, INFO or DEBUG.

If you would like to pull out different types of errors into different files, you can use this in your syslog configuration:
local1.=alert /var/log/local1.strace.log

Note that the errors are not actually written until the request has completed. You can force them to be written with the following:
Kohana::$log->write();

You can also force this behaviour by setting Log::$write_on_add = TRUE; in bootstrap.php, but be aware there is an overhead to doing that.

If you would like to ensure that logging is setup before writing to the log, you can do the following:

if (is_object(Kohana::$log))
{
// Add this exception to the log:
Kohana::$log->add(Log::ERROR, $error);

// Make sure the logs are written:
Kohana::$log->write();
}

Categories: development Tags: ,

loads.in – how fast does your website load?

March 15th, 2011 1 comment

This is a very nice tool – loads.in.

You enter a URL and it shows you how long your site took to load, what was shown at certain intervals and a waterfall chart – from a certain location.

You can then choose another location from a whole list of continents and cities and repeat the test again from that location.

Categories: Uncategorized, Web Tags:

weinre – Web Inspector Remote

March 15th, 2011 No comments

I recently blogged about a remote JavaScript debugging tool that Remy Sharp had created.

Along the same lines, this is something similar going around today that re-uses the interface for the Webkit Web Inspector (which is a bit like Firebug).

You can read more information here or watch the video below for a cool demo.

Categories: development Tags: ,

Why Apple Didn’t Introduce a Retina Display in the iPad 2

March 12th, 2011 No comments

I talked in a previous post about the announcement of the iPad 2 (which went on sale yesterday in the US).

A lot of the announced features could have easily been (and were) guessed. One thing that was notably missing from the iPad 2′s specification though was the so called “Retina Display” that was introduced with the iPhone 4.

There is an interesting thread on Quora looking at the reasons this might be the case.

Basically, there are a number of plausible explanations:

  • Cost and availability of the parts
  • Adverse effect on battery life
  • Hardware requirements to drive such a display
  • Lack of competition
  • Hopefully we’ll see a Retina Display in the iPad 3.

    Categories: Apple Tags: , ,