Newsletter

Newsletter “Under The Hood” Spring 2012

On February 22, 2012   /   News & Events, Newsletter   /   Comments Off

The gearbit newsletter “Under The Hood” Spring 2012

Here’s the article that Google wrote around performance. At Gearbit, we’ve been seeing performance improvements turning off “Slow Start”  and “Nagles’s algorithm” in the TCP stack in the servers. We also have been concerned about “buffer bloat” That is mentioned, but they have achieved a whopping 64% reduction with “page load time” by a newly developed protocol that they call “SPDY”. It adds a session layer atop of SSL for muliple concurrent interleaved streams, that can be invoked from client or server. SPDY improves HTTP increasing the number of streams, so that data can be more effectively set. Traffic is still managed by TCP with algorithms that monitor the ACK times, providing a congestion control, so that the network links don’t get congested. This will save server, firewall and load balances resources. Just think, we might get others to quit blaming the network!

Ray



Google works on Internet standards with TCP proposals, SPDY standardization


http://arstechnica.com/business/news/2012/01/google-takes-on-internet-standards-with-tcp-proposals-spdy-standardization.ars

SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.

 

The usual HTTP GET and POST message formats remain the same; however, SPDY specifies a new framing format for encoding and transmitting the data over the wire.

 

Streams are bi-directional, i.e. can be initiated by the client and server.

 

SPDY aims to achieve lower latency through basic (always enabled) and advanced (optionally enabled) features.

Back to Top

Newsletter “Under The Hood” Winter 2012

On June 12, 2011   /   News & Events, Newsletter   /   Comments Off

The Gearbit newsletter “Under The Hood”

When examining the ongoing health of your network, it’s
important to have those important statistics. Most of us
use systems that show the up-down status, tell us the
utilization of various segments and ports of the network.
Even have some ability to measure response time. Not
to mention server performance, some status of DNS and
the firewall. But is that enough? When faced with an
application response time is slow, or VoIP quality is poor
will the statistics give you the answer?
Recalling a response time problem at a finical institution, a few techs gathered together in the bosses office to device a
game plan. As the information unrolled, with each person giving their thoughts on the matter, the list of things to check
began to grow. One tech insisted that the wiring needed to be redone at this location. He was convinced it had to be the
problem. Well, that was his area of expertise and he had just completed a site tour of this location. It was a mess. But was
that the problem? How do you know? I’ve found locations where this is the problem.
I find going back to the basics is needed from time to time. Ask yourself how did the information get from client to server
and back again? Starting at the Client PC leaving the operating systems, through the network interface, on the wire
through the switches, routers, firewalls, WAN compression, and oh yea then the cloud.
Getting to this information can sometime only be compiled with a protocol analyzer, viewing the packets and
understanding the traffic flow. Even today’s tools, such as Wireshark, will present this information to you in charts, graphs,
but it’s important to view the packet flow, down to the transaction to see if all is well.
Better analysis delivering and building more credibility diagnostics.
Our goals are to make
• A more transparent network operations
• Rapid problem identification and reporting for immediate resolution
• Improved efficiency in network information management with creditable findings
• Delivering faster and better decision making
• This leads to more transparent network operations to the end user.

To download a copy go to: (download pdf)

Back to Top