TCP Overhead

by Michael CarterFebruary 1st, 2008

I’ve been profiling Orbited recently in an attempt to further optimize the system for Comet performance. I expected the parts of the code pertaining to string parsing would be the most CPU intensive parts. Turns out that the function parse_http_request() is actually third on the list of total CPU usage. The first is socket.accept() and the second is socket.close(). The implication for Comet is that polling can have drastically reduced performance, even ignoring the fact that some poll requests are wasted (that is, there is no new data to return.) Any polling transport that has a poll interval less than the keep-alive value of that the web server could be substantially less efficient than long polling would be on that same server, because with long polling all but the initial request would be sent over the same keep-alive session.

A second implication has to do with the fact that some Comet servers, such as Orbited, act as a proxy for the application. If the application sends a “Connection: close” header, and Orbited proxies that directly, then the connection must be re-opened for the next request, even if it’s an HTTP request destined to be held open for Comet communication. Therefore, a good optimization for hybrid proxy/Comet servers is to rewrite HTTP/1.0 or “Connection: close” headers as “Connection: keep-alive” and “Keep-alive: X” where X is the Comet server’s default keep-alive value.

Comments are closed.

Copyright 2015 Comet Daily, LLC. All Rights Reserved