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:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
MaxConnectionsPer1_0Server 10
MaxConnectionsPerServer 10
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.
Sincerely,
Anatole Tartakovsky
A blog Flex Shortcomings has been published on April 1. At first, I thought it’s a joke, but the author seems to be serious. These are some responses from Farata.
By Yakov Fain:
1. IntellijIDEA 7.03 started supporting Flex, but this support is limited. This year the version 8.0 will be released which will compete with Flex Builder. And this is great, because tha latter has a lot of room for improvements.
cheap mp3 Jennifer Lopez DVD album Era download album Madonna free Jennifer Lopez song DVD melodies Marcus Johnston get Jennifer Lopez track CD melodies Rodney Atkins download The Cranberries mp3 download John Mayer track get mp3 The Cranberries download Rodney Atkins mp3 CD mp3 Nine Inch Nails download Madonna melodies download Madonna music buy song Era cheap MOBY album cheap Sting track free Sting song free track Marcus Johnston get The Cranberries song cheap music MOBY buy music Sting get Madonna music download melodies The Cranberries DVD album Duran Duran free track Duran Duran cheap Enigma music get mp3 Contemplacion download track Sorry download Enigma album CD melodies Nine Inch Nails buy John Mayer song cheap Rodney Atkins music download Jennifer Lopez album DVD album Sorry cheap Sting music DVD track Marcus Johnston CD mp3 The Cranberries cheap album Jennifer Lopez get Marcus Johnston album download music Era cheap Duran Duran track cheap MOBY melodies get Marcus Johnston track buy mp3 Nine Inch Nails get MOBY melodies download track Jennifer Lopez cheap Madonna song get song Sting download Nine Inch Nails song cheap MOBY mp3 free John Mayer album buy melodies Duran Duran buy Jennifer Lopez song get music MOBY CD mp3 Marcus Johnston get Enigma album free album Era download album Era CD music Rodney Atkins
2. Generics is one of the most confusing Java elements. The lack of generics in AS is a plus
3. No Concurrecny. Flex UI was designed as a single threaded app, with absolute different model of screen refresh if you compare it with Java Swing.
Flash player applocates time slices (frame events) to the clients CPU (screen refresh, AS code, events). The calls to the servers that are originated from
the client define callbacks that will be called when either results of faults are returned from the server. This model is cleaner than messing
with the dispatch thread in Swing. Also, it eliminates “frozen screens”.
4. No dependency injection. This is just wrong. Flex is an event driven environment that allow lose coupling design of components.
If interested, I blog on the subj at http://flexblog.faratasystems.com/?p=246
5. No abstract classes. True, but this is no big deal
6. No method overloading. Action Script has a way to define methods with variable argument list (see …rest args). This allows to emulate
method overloading if need be.
7. No constant in interfaces. True. I can live with that.
By Anatole Tartakovsky:
Vectors supporting types are the part of the next release – and are billed more of performance/coding help then language enhancement. Most of the Java 5 constructs are not really applicable to ActionScript 3 – for fair comparison you need to use Java 7/8 with dynamic scripting language support – and then the way you speak that language changes profoundly.
For example, compare how enum support evolved in Java over the years – starting with patterns – and you would think of language as of evolving environment. I was coming to Java in ‘97 from C++ and I thought of it as a very poor language. 10 years made it almost tolerable – but I still miss ability to redefine operators – does it really matter to anyone who never did it in the first place?
The code for model view controller you are basing your generics case upon is really bad way to do client side software. Not using generics actually allows for more generic code and better reuse of controls and libraries. That allows smaller libraries to be streamed to the client. It is common to take large Flex application ( >20,000 lines of code) built by Java shops, then re-build them using dynamic coding techniques and more generic code – ending up with less then 25% of the original size. And is more usable as you can deliver relevant pieces of code when you need them – rather then preloading very large codebase at once.
Multithreading is great thing – when it works – and that still require some skills in almost every environment. If you are up to multithreading, it is not hard to provide solution that instantiate and synchronize multiple Flash VMs
Dependency injections – again – Flex uses and promotes factories, gives you annotations both design time (code generator) and run-time (interpreting annotated type info). Combined with built-in introspection ( ie you have DYNAMIC language) it is much more then following pattern that fights with limitation of the language. With e4x XML/object model) and NATIVE getters and setters and Proxy objects you can build your beloved patterns – but time will be better spent on reading framework code and understanding patterns written natively using language
Every language and framework has it’s strong and weak points. I would not use Flex for a few things – but there is no comparable portable environment for building RIA at this point. Learning new language is fun – as long as you approach it as learning process.
Disclaimer. Farata Systems is an independent software vendor and consultancy. We are not getting paid in any shape or form by Adobe for promoting Flex.