Posts Tagged ‘sockets’

IE 8 is coming…are you ready?

April 18th, 2008 by smp | Comments | Filed in Web Performance

So, Microsoft is releasing Internet Explorer 8 later this year, and a Beta is available now.

The question is, are you ready for it?

Internally, the tech savvy folks (myself included) have been tossing around the football of how to tackle it. The leap from 2 to 6 connections per host, on top of the basic rendering challenges that come with any new browser release are enough to make a Web team’s collective hive mind melt.

So, the bright team at Gomez are developing an IE 8 readiness kit.

Sounds like a great idea.

Why do you need to be concerned at a network level?

Let’s see…Well, while 6 simultaneous connections may be faster for clients, what happens to the TCP stacks of the devices that handle all of these connections, especially as more and more people start using IE 8?

Imagine that every Firefox user is using FasterFox, and then IE 8 comes along.

Do you have enough TCP sockets?

How quickly are sockets that are ready to be recycled actually recycled?

Are you really ready?

:-)

Tags: , , , , , , , ,

Dear Technorati…

July 8th, 2005 by smp | Comments | Filed in smp

You have noted that you are experiencing some performance issues related to high load (here). So I investigated and found that all the servers at the hostname www.technorati.com are responding with HTTP/1.0 headers and are explicitly closing the connections to the clients.

Why?

This will not relieve the performance problems. In fact, doing this may make the situation worse. The only way that this will not cause an issue is if you have tuned the kernel on these servers to go through an EXTREMELY fast TCP teardown process on the server side.

If you haven’t done this, go run a netstat -vanp on your www servers. See all the fin_wait, fin_wait2, closing and time_wait states? These are sockets that can’t be used again until the kernel releases them.

Now, Turning on keep-alives or persistent connections on the www servers will:

  1. Reduce the total number of connections per client
  2. Reduce the number of sockets “hung” in the teardown process
  3. Improve performance by reducing the network overhead required by the client and the server

The only caveat is to reduce the keep-alive timeout to something like 4-5 seconds so that these connections don’t wait for traffic forever.

Improving performance through disabling persistent connections is a myth. HTTP/1.1 was adopted for a reason. Use it wisely and your will reap the rewards.


Technorati: , , , ,

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,