The latest betas of IE and Mozilla increased default number of simultaneous parallel HTTP requests per domain/window from 2 to 6. It is the biggest new feature in AJAX world I have heard in the last 3 years. For current crop of AJAX sites serving real WAN connections it means doubling the load speed, fewer timeouts/reliability issues. By the way, most of Opera and Safari performance gains over IE and Mozilla are attributed to the fact that they use 4 connections instead of standards recommended 2 by default.
The fact that increasing the number of parallel connections increases throughoutput is very simple to understand. Today’s Request/response approach to communications is very similar to village bike concept – you have few very limited resources that travel back and forth, you wait till it is your turn, and hope that the guy before you does not get lost – otherwise you need to wait till all hopes are gone (called timeout) and the community provides you with a sparkling new bike circa 1996. In most cases it is too late anyway and user moved to a different page/site. As the travel destinations become more distant (WAN) you are exposed to real world troubles of commuting – latency (500ms for geostatic satellite network), bandwidth limitations, jitter (errors), congestions (your local ISP is also trying to be TV broadcaster AND new AT&T), unrecoverable losses, etc.
Obviously, more bikes mean that with some work on street and traffic planning you can get much better performance and reliability. You might even go crazy and allocate one bike to sheriff/fireman/village doctor so he will provide information on conditions and lost/damaged goods. You can route important goods in parallel so they would not get lost or damaged that easy. You can really start utilizing long running connection for real “push” now. But before we do go crazy let us look carefully what has been happening in the last 10 years – how early adopters of AJAX/RIA survived.
Increasing the number of HTTP connections was ugly trick most of enterprises we worked with quietly rolled out in the browser builds/service packs in the beginning of the century. In IE you apply changes to registry keys:
With Mozilla you recompile the whole browser and apply few other performance tricks along the way. It does solve most of performance and reliability issues for a SHORT WHILE. The main reason is that without imposed limits, software increases in size faster than Moore’s law for electronics. And , unlike private networks in enterprises, without proper “city framework” rampant requests will cause overall Internet meltdown as initial rollout of more capable browser will give them unfair advantage in terms of bandwidth share – 3 times as much compare to current crop, causing QoS problems on older and slower networks. In other words, it potentially has very real potential to cause more of the same problems it tries to solve.
Most enterprises had to control QoS of communication for their clients. They created and adopted number of p2p solutions that provide more efficient communication models. Basically they fall into 3 categories:
1. HTTP Batching
2. Binary components dealing with sockets directly
3. Pluggable protocols
The last option did not really catch up in popularity, even though it allows moving most of the problems from the browser level to OS level. We will cover only the first 2 options.
HTTP Batching is combination of few technologies with close resemblance of Tokyo metro ushers working on family motorbikes. As an example, Flex/Flash AMF protocol tries to squeeze every bit of bandwidth and optimize queuing of the requests in the most efficient way – both on client and server. The result is very good – you use maximum bandwidth, and lines are kept short. As a matter of fact, the results were so good, that most of our clients, even if they need to use WebServices or conventional HTTPServices, use AMF to proxy requests via AMF enabled server, making it deliver results from legacy servers more efficiently. It is loads better than non-batched requests/responses. And it plays nicely with current infrastructure as it piggybacks on the existing browser HTTP requests. However, for critical applications or plain bad infrastructures the problem remains: there are no QoS or QoE (quality of experience) built on HTTP level, so there are potential problems with queues overruns or lost packages.
From purist point of view it was a mistake to let mathematicians and physicists mess with communications and come up with HTTP model. Binary “always on” (re)connected socket protocols are way more logical and efficient. Unlike request/response model typical socket connection is like 2 way highway, with data moving in opposite directions independently. But before we would fully depart into Communications 2.0 world, let us talk a bit how HTTP shapes up these days.
As I was saying, disconnected model of HTTP 1.0 was not practical. Overhead of connecting/disconnecting was not tolerable, and for the last 8 years I have not seen single desktop browser using it. It has been completely replaced by HTTP 1.1 – the protocol that keeps connections open beyond request/response so next communications happen faster. Underneath, of course, there are 2-way sockets that stays open – but browsers diligently follow old model and ignore the possibilities.
As browsers started to get into real applications, the need for real-time data forced people to look into better solutions then polling for data – and few “push” solutions appeared. While they were different in implementations, the main theme was the same – browser gets requests, holds it for long time, flushing packages down when it becomes available. The packages reach the browser and are either interpreted by programs upon arrival or executed (if packaged as <script/> sections). The important part is that people started to see that server driven model is valid and better for some applications.
J2EE final specification and standards (JSR 315: Java Servlet 3.0 Specification) are planned for the end of the year, however, there is a number of open source and commercial implementations of proposed “Comet” model today (including Python-based and others). They can be very different in approach and implementation – capitalizing on new non-blocking io, optimized threads or more efficient native sockets implementations – but they are fundamentally common in breaking request/response paradigm. The idea is that the server provides second model for requests handlers in addition to conventional one. Handlers that are marked to support that model will receive 4 events – “connect”, “read”, “error” and “disconnect”. Adding event model to the server side brings symmetry to the client/server programming model and greatly simplifies asynchronous programming code. “Connect” and “Disconnect” events define lifespan of the “connection” object available for communications. “Error” event notifies of low-level errors in the transmission protocol. “Read” event means that there is request coming from the server and allows server to read and process it. Server keeps “connection” and “response” objects and writes/flushes information to the client as needed.
Let us see how this model is different for fine granularity requests common for today’s AJAX applications. Pretend you are sitting ( like me now ) at a coffee shop with lousy Wi-Fi connection sporting 1 sec latency for typical webservice eBay response, watching for 30 items. With current browser settings, it takes you 15 seconds to refresh all 30 items. With 6 connections, it will reduce it to 5 seconds – but will require 3 times infrastructure in between. With “Comet” type requests you can send all 30 requests without waiting for single response ( the same will be done with AMF HTTP batching) and will receive all 30 responses asynchronously – usually within 2 seconds. With HTTP Batching, you would get all 30 responses at once, and need “sorting” adapters on both sides to distribute pieces to proper responders.
Great advance, and just in time when other commonly available technologies were about to make the whole model obsolete. Surprisingly, it also strengthen the position of competitive technologies – but that is to be covered in Part 2.